Shared AI agents for customer onboarding handoffs

Agent Swarm can coordinate an onboarding handoff from sales to delivery by keeping one shared account record that every agent and person reads, with a person approving anything the customer sees. Shared AI agents do this only after your team configures them. Nothing ships ready-made: you connect your own sales source and decide which steps need a person.

That verdict covers one specific problem. Your team closes a deal, and the knowledge needed to deliver it stays with the people who sold it. An agent can carry that knowledge across the handoff, and it can carry only what your team gives it a place to put.

Why onboarding loses context

The handoff is where onboarding fails, usually because the knowledge sits somewhere the next team does not look.

Sales notes live in a CRM record or in a document the salesperson wrote for themselves. The requirements the customer confirmed on a scoping call live in an email thread, a signed order, or a spreadsheet someone maintains by hand. The operations owner who will run delivery and the technical owner who will do the integration sit in different tools, with different views of the same account.

Then the kickoff meeting happens, and the first ten minutes go to rebuilding what was already settled. Someone asks whether the customer approved the later start date. The salesperson is on another deal. The answer exists, in a thread nobody opened, and the meeting proceeds on a guess.

None of that needs a large company. It happens at forty people and at four hundred. What changes with size is the number of hops the context makes before it reaches the person doing the work.

An illustrative onboarding handoff

This walkthrough is illustrative. It describes an invented company, a design assembled from documented Agent Swarm pieces, and no measured result. No customer is named and no deployment is being reported.

The invented company sells and installs commercial kitchen equipment, then services it. A regional restaurant group signs an order for four sites. Here is one way the handoff runs.

Trigger. Your team picks the event that starts onboarding. A closed deal in the sales tool and a signed order both work; the point is that one event starts the same sequence every time, so nobody has to remember to begin. The run also has to tolerate a deal that closes without an order attached, which is the case that usually slips through.

Source of truth. Each account gets one directory in agent-fs at a predictable path, such as customers/<account>/, following the documented per-customer working directories pattern. That folder holds the sales notes, the confirmed customer requirements, the open questions, the meeting transcripts and a short README summarizing current state. The README is the first file anyone opens, and appending to the folder rather than overwriting keeps the notes usable as a record of what the team knew and when.

Owner. One person is accountable for the onboarding decision, named in the directory before the first draft exists. At the invented company that is the delivery operations lead. The owner is not the person who approves every message; the owner is the person who resolves a conflict the agent cannot.

Handoff. An agent reads the directory and drafts an onboarding brief: what the customer bought, the requirements that were confirmed, the dates that were agreed, the questions still open, and the people on each side. The delivery operations lead and the technical owner review that draft in the folder. Reviewing a brief means editing a shared document instead of rebuilding one, and both reviewers start from the same text.

Exception path. Missing or conflicting requirements go to the named owner with the draft attached, and nothing is sent. In the invented example, the electrical specification for one site never arrives, and a second site's delivery window contradicts the date in the sales notes. The agent lists both gaps at the top of the brief and posts the escalation where the owner works. The customer hears nothing until a person decides what to ask.

Acceptance checks. Before the brief goes to review, deterministic checks run on the fields your team declared required. The list covers the customer name and site list, the contracted dates, duplicate accounts and the status of each open question. A check that fails keeps the brief out of review and reports the failing field. These are ordinary script checks, and much of the reliability comes from them, because they do not depend on a model noticing something.

Customer-facing step. Any email or message to the customer waits for a person's approval. The human-in-the-loop gate pattern covers the mechanics: a workflow node pauses, posts to Slack, and resumes only when a person responds. Define the approve and reject branches, and set a timeout with a fallback so a forgotten approval does not wedge the run. The gate belongs on the irreversible step, which here is the send.

A short version of the same sequence:

1. The deal closes, and the trigger names the account.
2. The agent writes the account's sales notes, confirmed requirements and open questions into customers/<account>/.
3. The agent drafts the onboarding brief from that folder.
4. Scripts check the required fields, dates, duplicates and status.
5. Operations and the technical owner review the draft.
6. Gaps go to the named owner with the draft attached.
7. A person approves the customer message, and only then does it leave.

Two of those steps have an agent writing a document. The rest is file layout and a gate, and the gate is what keeps the customer out of the loop until a person has read the draft.

What it takes to set up

None of this is packaged for your business. These are the pieces your team owns.

• Deployment-specific skills and integrations. Connecting the sales source and any mail sender is your team's configuration work. The proactive customer support playbook shows the shape of that work: Lead, Researcher and Forward-Deployed Engineer agents, per-account directories, transcripts appended after calls, a human reviewing drafts, and AgentMail sending from a verified per-account inbox after approval. Onboarding adapts those pieces, and the connections to your sales and mail systems are yours to build.
• The agent-fs directory layout. One folder per account with a predictable path, a README at the root, an append-only convention, and a place for customer-facing drafts kept separate from internal notes. The separation turns a redaction pass into opening one folder.
• Human review gates. Name the steps a person must approve and write both branches for each. Gate only the irreversible ones, such as a send to the customer.
• Access boundaries. Decide which agents read which account folders. The agent that drafts the internal brief does not need the customer inbox, and the agent that sends does not need every account.
• An owner. One person accountable for the workflow and for the directory, who answers when a check fails or a requirement conflicts. Without a name, the escalation path is a channel nobody reads.

Two roles carry it: the onboarding owner who decides, and the operator who owns the configuration.

When a simpler tool is the better fit

The setup above is work your team owns and keeps working, and some teams should not take it on.

If onboarding is one team with a fixed checklist, the checklist is the tool. A project template or a spreadsheet holds the same information, and nobody maintains a directory layout for it.

If an onboarding or CRM tool already holds the handoff and the work stays inside it, use that tool. The gap this design closes appears when context has to move between teams whose systems do not talk, and one system removes the gap.

If nobody can name the owner, fix that first. An agent escalates to a person, and without a person the escalation goes nowhere.

FAQ

How can AI agents coordinate customer onboarding handoffs between sales and operations?

They coordinate by reading from and writing to one shared account record instead of passing messages between teams. The agent turns what sales recorded into an onboarding brief inside the account's folder, checks the fields your team declared required, and routes missing or conflicting requirements to a named owner. Operations and the technical owner review the same draft. Anything the customer sees waits for a person's approval.

How do shared AI agents keep customer context across onboarding teams?

By keeping the context in files rather than in one agent's session. Each account has a folder in agent-fs with a short README, the sales notes, the confirmed requirements and the open questions, plus the call transcripts. A later agent in a different session reads that folder before acting, so it starts from the account's current state. Because the folder is appended to, the next person can see what changed and when.

Where to go next

Two documented pieces carry the design: per-customer working directories and human-in-the-loop gates. The proactive customer support playbook applies both to an account team, and it is the closest published example to the handoff above. For how this work fits alongside the rest of a small company's recurring operations, the small-company workflow atlas covers the wider set. The case for one shared record across agents is in our note on shared context.

If your team runs onboarding across more than one system and no single person holds the account's current state, this design is worth one workflow. Start with one account and one named owner.