AI adoption across departments: fix the handoff first
Cross-team work breaks at the boundaries: definitions, systems of record, approvals, and exceptions. Those boundaries should shape the pilot.
Choose one handoff with an accountable owner
Midsize organizations often have enough systems to create repeated coordination work and too little spare capacity to maintain a separate automation in every team. A practical starting point is one handoff, such as sales-to-delivery or project-to-finance. Define the point where responsibility changes. Then name an owner for the entire handoff, even if several departments own the underlying records.
For an illustrative sales-to-delivery pilot, the desired result is an internal readiness brief. It compares the accepted scope, promised dates, required contacts, and unresolved dependencies. The brief should make gaps visible before a project begins. It should not silently rewrite the sales agreement or treat an informal note as a customer commitment. Those decisions remain with the relevant authorized people.
Agree on definitions before connecting systems
Different departments can use the same word for different states. “Approved” may mean a salesperson accepted the opportunity, finance cleared the terms, or delivery confirmed capacity. Document which status is authoritative for each decision. Include identifiers that link records across systems. Otherwise an agent may combine two similarly named customers or interpret an incomplete status as permission to proceed.
Create a minimum handoff contract: required fields, authoritative sources, validation rules, and the receiving team. State what happens when a field is absent. This is useful regardless of whether the implementation uses dots, conventional automation, or custom software. The agent can help assemble information, but the organization must decide which information establishes readiness and who may override a missing requirement.
Map access by role and action
A cross-team workflow is not a reason to grant every participant broad access to every source. Identify the information the workflow needs and the account under which each connection operates. Review source-service permissions and app actions separately. A summary intended for delivery may need to exclude commercial material visible to sales. Design the output boundary as deliberately as the input connection.
Dots remains a personal-agent product, with workspace controls and supported connections. Avoid assuming that several personal dots automatically become a centrally managed service. If the handoff requires shared queues, a dedicated interface, or application-specific permissions, assess a custom integration or agent application. The architecture should follow the operating requirement rather than the product used in the first demonstration.
Make exception handling part of the design
List the failures that already interrupt the manual handoff: missing approval, contradictory dates, an account mismatch, a duplicate record, or a unavailable source. Decide who resolves each condition. The initial workflow can prepare an exception list with links and a named owner. It should distinguish “nothing missing” from “unable to check,” because those outcomes require different responses.
For any system write, plan duplicate prevention and recovery. A retry after a partial failure must not create a second project or send another customer message without detection. Keep irreversible or consequential steps behind an explicit business control. These engineering requirements apply whether a model suggested the action or deterministic code selected it. A successful happy-path demonstration does not validate the recovery design.
Pilot with both sending and receiving teams
Evaluate the output with the team that prepares the handoff and the team that receives it. A report can be accurate yet poorly suited to the receiving team's decision. Ask both sides to examine the same representative cases and document disagreements. Resolve those disagreements in the handoff contract rather than accumulating incompatible instructions in separate conversations.
Measure review effort, missing requirements caught, repeated corrections, and delayed exceptions. Use observations from comparable work and keep the limits of the sample visible. The value may be clearer accountability or fewer avoidable questions before it becomes a measurable time reduction. Resist a broad rollout until the people handling the exceptions agree the process is understandable and sustainable.
Establish change ownership after acceptance
Name owners for the source systems, the workflow configuration, and the business acceptance criteria. A renamed field or new approval step can break a previously useful process. Set a simple change procedure: identify affected workflows, update the contract, run the relevant acceptance cases, and record the result. Include the procedure for removing access or stopping recurring work when ownership changes.
Expand one adjacent handoff at a time. Reuse components where the behavior truly matches, while preserving each team's distinct requirements. A midsize adoption program becomes durable when it improves the connections between departments and leaves those connections documented. The technology supports that operating discipline; it cannot substitute for an agreed definition of who owns the next decision.
The source record
Sources & editorial notes
Primary documentation checked September 29, 2026. Our implementation recommendations are editorial analysis. Illustrative workflows are proposed examples, not completed client case studies or performance claims.
- Tasks and memory OpenAI
- Apps and connectors OpenAI
- Manage dots permissions and capabilities OpenAI
- Control your dot OpenAI
- Agents API overview OpenAI
Found something that needs updating? Contact the editorial team with the passage and a supporting source.