Frances @ Waxell
When every AI agent handoff goes through you, you're the bottleneck. Here's how to build multi-agent workflows where agents pass work without you in the middle.

A multi-agent handoff is when one AI agent completes a task and passes its output directly to a second agent for the next step — no human routing it between them. In Waxell Connect, handoffs work through the workspace: one agent writes its output to a file, the next agent reads from it, and the work moves forward on its own.
My blog pipeline runs as three separate agents. One drafts the post. A second fact-checks it against live sources. A third posts the result to the channel for my review. No agent session contains the other agents' work — they pass output through workspace files. None of them wait for me.
Before: Me as the Routing Layer
Any multi-step task used to have me in the middle of it. Finish a draft in one AI session. Close the tab. Open a new session. Paste the draft in. Say "now fact-check this."
My context for any AI task lived in a note in my project management tool that I'd manually copy-paste into each new chat session. The agent only knew what I put there. For a single-step task, fine. For anything with multiple stages — write, then check, then post — I was the routing layer. Every pipeline moved at whatever speed I happened to move.
The bottleneck was me.
The Workflow, Step by Step
The blog pipeline is the clearest example I have of this running in practice.
Step 1: The draft agent. A scheduled task fires each morning. Every Cowork session the draft agent opens specifies the blog workspace — Cowork enters it and reads the context files automatically before the agent does anything. It reads CONTENT_LOG.md to see what post is next, reads VOICE_GUIDE.md and the topic queue, writes the draft, and saves it as 11_when-agents-hand-off-to-agents.md to the workspace.
Step 2: The fact-check agent. A second scheduled task fires after the first completes. This agent enters the same workspace, finds the new draft file, and verifies specific claims against live sources using Claude in Chrome. It saves a corrected v2 file to the workspace alongside a structured fact-check report.
Step 3: The channel post. A third task picks up the v2 file and posts a summary to the marketing/blog/connect channel, with flags for anything that needs my input.
Work passes through files in the workspace. Agent A writes; Agent B reads. Neither has any knowledge of what happened in the other's session. That's the full handoff mechanism.
This is how it works in my setup, using Cowork as my interface for Connect. Connect is also accessible via API and web UI — if you've built your own agent tooling or are accessing Connect programmatically, the workspace-as-handoff pattern works the same way.
What Makes This Work
Most multi-agent setups fall apart at the handoff, not inside any one agent. The 2026 research on this is consistent: the failures are almost always context-transfer problems at the boundary between agents, not capability problems within them.
The work needs somewhere to land between agents.
If Agent A writes to a chat window and you paste that to Agent B, you're the handoff. If Agent A writes to a file in a shared Connect workspace and Agent B is scheduled to read from that workspace, the handoff runs without you. The workspace is the contract: Agent A knows where to write. Agent B knows where to read. Neither needs to know anything about the other.
This is also why the structure of what agents write matters as much as what they write. A consistently formatted markdown file with clear section headers is something a downstream agent can navigate predictably. A freeform output dump isn't. The fact-check agent in my pipeline doesn't parse the full draft looking for claims — it reads specific sections, because the draft format is consistent enough to make that reliable.
AutoGen, Microsoft Research's multi-agent coordination project, put this plainly back in 2023: building a complex multi-agent workflow comes down to defining agents with specialized roles that know what to read and what to write. The hard part isn't the agents — it's the shared layer where output lands.
Once agents are reliably writing to and reading from the workspace, adding a new step takes about ten minutes. Define what the new agent reads. Define what it writes. Schedule it after the previous step.
What You Could Build
The blog pipeline is one version of this. The pattern holds for anything with multiple sequential stages.
Customer support: A triage agent classifies an incoming request and writes the classification plus the customer's workspace context to the ticket file. A response agent reads from that file and drafts a personalized reply. A quality agent checks the draft against tone guidelines before it posts. No manual routing at any step.
Content localization: A writing agent drops a draft to the workspace. A translation agent picks it up and produces three language versions. A localization agent reviews each one for regional accuracy and posts them to the appropriate review channel. I built a version of this for the help docs and it cut the review cycle from two days to about four hours.
Sales workflow: A research agent writes a prospect briefing file to the workspace. A pitch agent reads it and drafts the outreach. You review the draft in the workspace before it sends — one checkpoint, not three manual handoffs.
None of these require you to be the routing layer. You need a workspace both agents can read from and write to, and tasks scheduled to run in order. Start with the simplest version: one scheduled task that writes a file to a workspace, a second that reads it and does something with the output. Build that. The rest is variations on the same structure.
If you're not yet on Connect and want to try it: waxell.ai/get-access.
FAQ
What is a multi-agent handoff in Waxell Connect?
A multi-agent handoff in Waxell Connect is when one AI agent completes a task, writes its output to a workspace file, and a second agent reads that file as input for the next task — with no human routing it between them. The workspace is the coordination layer. Agent A writes to it; Agent B reads from it. As long as both agents know the workspace path and the expected file format, the handoff runs on its own.
Why does the workspace matter for multi-agent coordination?
Without a shared, persistent location for output to land, every agent handoff requires a human in the middle. A Connect workspace gives agents a structured place to pass work from one step to the next. The output doesn't disappear when an agent session ends — the file stays in the workspace until the next agent picks it up, whether that's two seconds later or two hours. This is what makes async agent pipelines possible at all.
How is this different from just using one agent for everything?
Specialization and debuggability. A single agent handling research, drafting, fact-checking, and posting simultaneously manages competing objectives in one pass. Separate agents with separate jobs produce more consistent output, and when something goes wrong it's clear where. When the fact-check agent flags an error, I know which step introduced it. When the voice drifts, I know which agent to adjust. With a single agent doing everything, I'd be guessing.
Do agents in the pipeline need to communicate with each other directly?
No. In the orchestrator-plus-subagent pattern — the current standard across most production multi-agent systems — each agent runs in its own context window, completes its task, and writes output to the shared workspace. Agents don't need a direct communication channel. Sequencing is handled by the scheduling layer. Agents read, do their job, and write.
Can agents in different workspaces hand off to each other?
Yes. Connect's channels let agents in one workspace post output to a channel that a different workspace monitors. A completed task in one workspace can trigger work in another without any direct agent-to-agent communication. The channel acts as the async relay between distinct workflows.
Do I need Cowork to run multi-agent workflows in Connect?
No. Cowork is the interface I use to work with Connect, but it isn't required. You can build multi-agent pipelines through the Connect API, the web UI, or any agent tooling that reads and writes to Connect workspaces. The coordination layer is the workspace itself, not whatever interface sits on top.
Sources
"Multi-Agent AI Systems in 2026: What the Research Actually Says." FlowHunt, 2026. https://www.flowhunt.io/blog/multi-agent-ai-system/
Wang, Chi, et al. "AutoGen: Enabling Next-Generation Large Language Model Applications." Microsoft Research, September 25, 2023. https://www.microsoft.com/en-us/research/blog/autogen-enabling-next-generation-large-language-model-applications/
Agentic Governance, Explained




