Why Do Multi-Step Automations Break at the Handoff and Not Inside the Steps?

Why do multi-step automations break at the handoff and not inside the steps?

Because each step is tested on its own and the space between steps is not. A step has inputs you chose and outputs you checked. A handoff is an assumption about what the next step will receive, and assumptions do not throw errors. They just produce quietly wrong work until somebody downstream notices.

This is the pattern I keep running into, whether the two sides of the handoff are two AI agents, two SaaS tools, or a script and a human. The individual pieces are usually fine. What fails is the contract between them, and nobody wrote the contract down because it felt obvious at the time.

I build automations in production for real businesses. The Ajust workflow I maintain runs on Airtable with WhaleSync moving records between systems, and it has delivered more than 25,000 cases, helped more than 400,000 people, and saved more than 50,000 hours. Almost none of the hard work in that build was inside a single step. It was in deciding exactly what each stage owed the next one.

What is a handoff in an automation, and why does it deserve its own design?

A handoff is the moment one part of a workflow stops owning a piece of work and another part starts. It carries data, but it also carries meaning: what this record is, what state it is in, and what the receiver should do next. Most automations pass the data and skip the meaning.

Think about what happens when a form submission becomes a CRM record becomes a task becomes an email. Four systems, three handoffs. Each handoff is a place where a field can arrive empty, a status can be ambiguous, or the same record can be processed twice because the first system retried. None of those are bugs inside a step. They are gaps between steps.

The reason this deserves deliberate design is that handoffs are where retries, partial failures, and timing live. A step either runs or it does not. A handoff can half happen. That is a fundamentally different class of problem, and it needs a fundamentally different kind of attention.

What does a well-specified handoff actually contain?

Four things, and the clearest statement of them I have read comes from Anthropic's engineering write-up on the multi-agent research system they built. Anthropic says that "each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries." That list transfers cleanly to automations that involve no agents at all.

An objective is what this stage is for, stated in one sentence a human could check. An output format is the exact shape of what comes out, field by field, including what an empty value means. Guidance on tools and sources is which systems are authoritative, so two stages do not disagree about where the truth lives. Task boundaries are what this stage must not touch.

That last one is the one people skip, and it is the one that prevents the worst class of failure. If a stage does not know what it is forbidden from doing, it will eventually do it, usually helpfully, usually to a record that was already handled. Boundaries are not bureaucracy. They are how you keep two well-meaning components from overwriting each other.

What happens when the handoff is vague?

The same failure modes appear whether the workers are agents or automation steps. Anthropic reports that "without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information," and gives a concrete example from their own system where "one subagent explored the 2021 automotive chip crisis while 2 others duplicated work investigating current 2025 supply chains."

Read that as a description of a Zapier scenario rather than an AI system and it becomes very familiar. Two branches of the same automation doing overlapping work on the same record, because neither was told which slice was its own. Nothing errored. The logs are green. The output is duplicated.

Anthropic also describes early behaviours in their system that included "spawning 50 subagents for simple queries, scouring the web endlessly for nonexistent sources, and distracting each other with excessive updates." I would not generalise their specific numbers to your workflow, but the shape of the failure is worth internalising. Under-specified work expands to fill whatever budget you gave it.

Why does adding more agents make the cost curve steeper?

Because every participant reads context, and context is the thing you are paying for. Anthropic states that in their systems "agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats." Those are their measurements of their own architecture, not a universal constant, but the direction generalises.

They also report that "a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%" on their internal research eval. That is a real result on a specific benchmark they ran, and it is the honest counterweight to the cost point. More participants can genuinely be better. They are also genuinely more expensive.

The decision this leaves you with is not philosophical. For a given job, is the quality gain worth a cost multiple that grows with every handoff you add? For open ended research the answer is often yes. For a routing rule that moves a lead into the right pipeline the answer is almost always no, and the one-step version is the right build. I go through that trade in more detail when thinking about which workflows should not be automated at all.

How do you design handoffs between tools rather than between agents?

You write the contract into the data. In the Ajust build, records move between systems through Airtable and WhaleSync, and you keep that honest by making every record carry its own state rather than relying on which automation touched it last. A status field only one stage may write beats a page of documentation.

For Kismet Health I run CRM automation into HubSpot through Zapier, and the same principle applies in a completely different stack. The receiving system should be able to answer, from the record alone, what stage this is in and whether it has already been processed. If answering that requires knowing the run history, you have a handoff that will eventually surprise you.

The practical version is three habits. Give every record a state field with a short, closed set of values. Make the handoff idempotent, so receiving the same record twice produces the same result rather than a second invoice. And write the receiving side to validate what it got instead of trusting it, because the sender will change one day and will not tell you.

How do you test a handoff before it reaches real data?

By sending it the inputs you are afraid of rather than the inputs you designed for. The happy path gets tested automatically, because the happy path is what you built. What never gets tested is the record with a missing email, the one that arrives twice, and the one that arrives while the previous run is still going.

My habit is to keep a small set of deliberately awkward fixtures and push them through every stage boundary before anything touches production. An empty required field. A duplicate. A record whose status is already the status the stage wants to set. A payload that is correct but arrives out of order. Four ugly records will teach you more about a workflow than four hundred clean ones.

Run that before real customer records are involved, not after. I have written separately about why AI automations in particular deserve a rehearsal with fake data first, and everything in that argument applies double once more than one component is passing work along.

When should a handoff become a human checkpoint instead?

When the cost of being wrong is higher than the cost of waiting. That is the whole rule. If a bad handoff sends a wrong invoice, a wrong diagnosis, or a wrong message to a customer, the right design is for a person to see it before it moves. Everything else is an optimisation you can make later.

The trap is treating a human checkpoint as a failure of the automation. It is not. A checkpoint is a handoff with a slower, smarter receiver, and it follows exactly the same rules. The person needs an objective, an output format, and clear boundaries just as much as a subagent does. A review step that says only "check this" produces rubber stamping within two weeks.

Where I actually place checkpoints is at the boundary where a record first becomes visible to somebody outside the business. Inside the machine, let it run. On the way out, look at it. That single placement rule has prevented more embarrassment than any amount of error handling inside individual steps.

What should you do next?

Open the automation you trust least and draw the boundaries rather than the steps. For each boundary write four lines: the objective, the output shape, which system is authoritative, and what this stage must never touch. Most people find one boundary where they cannot answer all four, and that is the one quietly failing.

Then make the ugly fixtures and run them. If a boundary survives a duplicate, an empty field, and an out-of-order arrival, it is probably sound. If it does not, you have found the fix before a customer did. This is also the moment to ask honestly whether a stage needs to exist at all, because the cheapest handoff is the one you deleted. If you are weighing whether a workflow has outgrown its platform, I have written about the point where moving an automation into code becomes the right call.

If you are staring at a multi-step workflow that works most of the time and you cannot tell which boundary is lying to you, that is the kind of thing I enjoy untangling. Reach out if you want another pair of eyes on it.