The AI Handoff Failure Nobody's Job Is to Catch
An agent hands work to a person, the person hands it back, and nobody owns the moment in between. Headcount never caught that, and a named owner for every handoff is what does.
An AI agent hands a task to a person. A person hands something back to the agent. Nobody's job description covers the moment in between, so when that handoff fails, nothing happens: no error, no alert and no ticket. The work simply sits there.
The comfortable explanation is that the team was too small to watch it. That explanation is wrong, and believing it is expensive. At 200 people the same handoff fails the same way, and the only difference is how much money moves through the gap first.
So: where it breaks, why hiring more people was never the fix, and the specific control the ASD now recommends you put in its place.
Headcount was never a safety net
The story goes that a bigger business has enough people that someone will notice an unassigned lead, or an escalation nobody picked up. Not a deliberate system, the story admits, just headcount doing oversight by coincidence.
The word doing the work there is coincidence, because nobody's job covers it.
A 12-person team and a 200-person team fail identically when the same condition is true: no named person is accountable for a specific handoff. What headcount changes is the size of the pile before discovery, and it changes it in the wrong direction. A four-person business finds an unactioned escalation in two days because the customer rings the founder. A 200-person business finds it in six weeks, in a quarterly report, after forty of them, with a service level agreement attached to each one.

The four places the handoff actually breaks
1. The agent escalates and the escalation arrives nowhere specific. An AI agent hits something it cannot resolve and hands it off as a task, a notification or an alert. If that arrives with a person whose job includes reading it, fine. Usually it arrives in a shared inbox, a general notification feed, or with whoever is free, where it competes with everything else for attention and regularly loses. Size makes this worse: a shared inbox with three people in it gets read, and a shared inbox with thirty does not, because everyone assumes someone already has.
2. Nobody is checking whether the agent is still right. An agent answering from your knowledge base, or qualifying leads against criteria you set in March, keeps confidently doing that after your prices change, your offer shifts, or your ideal customer moves. The agent does not know anything changed. Nothing in your stack has an opinion about whether its answers are any good, which is the whole subject of the sibling piece on what happens when your AI agent stops being useful and says nothing. That piece is the detection half of this problem. This one is the ownership half.
3. The handoff crosses a boundary between two people's work. A lead arrives, gets partly processed by automation, and needs a person to finish the job. If it is unclear whose job that finishing step is, it sits in the gap. In a four-person business that boundary is the founder and the first hire. At 200 it is marketing and sales, and the gap is wider because the two people have never met.
4. Nobody reads the exceptions. Automation gets built and tested against the common case: the standard enquiry, the typical lead. The unusual request, the lead with a missing field, the question the agent was never built for, all pile up in whatever queue catches them, because handling exceptions takes spare time nobody has. That queue is the most informative object in your portal and almost nobody opens it.

Why "keep an eye on it" fails at every size
The obvious-sounding fix is to ask someone to watch things more closely. It rarely survives a real week, and it is worth being honest about why.
"Keep an eye on it" is not a task. It has no trigger and no due date, and nothing about it looks broken when it is missed, so it competes against work that has all three. Nobody is being careless: a piece of client work due today will always beat a general sense that somebody should probably check the automation.
Adding people dilutes that further. Ten people who might check is worse than one person who must, because each of the ten has already decided one of the other nine did.
Would you know if a handoff stopped working?
Most small teams find out when a customer tells them.
What the ASD actually recommends
This is where it stops being our opinion. On 1 May 2026 the Australian Signals Directorate's Australian Cyber Security Centre published Careful adoption of agentic AI services, jointly with CISA, the NSA and the cyber security centres of Canada, New Zealand and the United Kingdom. It is the first joint guidance those agencies have published on agentic AI, and the current Australian word on this exact problem.
Its position on oversight is not soft. It treats strong governance, human oversight, rigorous monitoring and explicit accountability as essential requirements for running agentic AI at all. What that means in practice, at three separate moments in an agent's work:
- While the agent works: monitoring tools that strengthen human oversight, with transparency designed into the application so a person can see what it is doing.
- At the risky step: approval steps and intervention points on high-risk actions, and human-in-the-loop review wherever the cost of an error is high.
- After the task: auditing and reversibility, which in practice means keeping a record of what the agent did that is complete enough to undo.
It also asks you to adopt agentic AI incrementally, beginning with low-risk tasks, to deploy in phases with restricted APIs, and to keep strict privilege controls and strong identity management, so an agent's actions can be told apart from a person's.
Read that list against your own setup. Most businesses have built the agent and none of the three.
The National AI Centre's Guidance for AI Adoption, published 21 October 2025, puts the same idea first among its six essential practices: decide who is accountable. A named person, per piece of work. A committee satisfies the wording and none of the intent.
The fix: an owner for every handoff
Four things, none of which requires hiring anyone. All four are the unglamorous version of what the ASD asks for.
List the handoffs, then put one name against each. Write down every point where the agent hands to a person or a person hands to the agent. Most teams find between four and nine. One name each, because a role does not read an inbox and a team does not either. This takes about an hour and it is the highest-value hour in the whole exercise.
Give every handoff a due date and a visible overdue state. A task with a due date, assigned to a named person, that goes visibly overdue when nobody actions it. A stuck handoff should be loud enough that it finds you, because anything that has to be looked for gets found in a quarterly review.
Put human approval on the consequential actions, and only those. This is the ASD's approval step, and the qualifier matters. Approval on everything gets switched off within a fortnight. Approval on the two or three actions that are expensive to get wrong survives, because the approver can see why they are being asked.
Book the review and give it an agenda. Ten minutes a month, in the calendar, with four questions: is the agent still working from accurate information, are escalations arriving and getting actioned, has anything about the business changed that the agent does not know about, and what is in the exception queue. Doing it on a schedule beats doing it when there is time, because there is never time, and it is where you notice the obvious gap, like the automations worth having before the financial year turns over.
If nobody internally has the spare capacity to own this properly, an outside partner covering exactly this is a normal arrangement at any size.
What that looks like written down
An example shape. The point is that every row has a name in it.
| Handoff | Who owns it | What overdue looks like |
|---|---|---|
| Agent escalates a support conversation | Named support lead | Task overdue after four hours, on a dashboard someone opens |
| Agent qualifies a lead, a person calls it | Named sales rep | Deal with no next step for three days appears on a list |
| Agent drafts, a person approves | Named marketer | Draft unapproved for seven days |
| Anything the agent could not handle | The automation's owner | Monthly exception review with a written outcome |
The times are examples. Yours come from what the work is worth.

What it comes down to
Automation rarely fails because the team gave up or because the wrong tool got picked. It fails at the handoffs, because no named person owns the moment when work changes hands, and no amount of headcount creates an owner. The ASD says the same thing in security language: it lists explicit accountability among the things you need in place before you run agentic AI.
The adoption side of this is covered in the ten reasons marketing automation adoption fails, and the fix for each. If you are building new agents, what HubSpot's Agent Hub and Agent Builder launched with matters for one reason: Agent Builder has approval steps in it, so the approval control becomes a setting instead of a habit. If an automation has already lost its audience, reviving it starts with finding which handoff broke first.
We are a HubSpot Diamond Partner, Certified in the Claude Partner Network, and we build on Claude, which mostly means we have found these gaps in our own portal first. Our AI Engineering service is largely deciding what the machine does alone and what a person signs.
Pick the handoff that would cost the most if it stopped tonight. Can you name the person who would find out, and would they hear it from your system or from a customer?
Who on your team would run the safety net?
On a small team the honest answer is usually nobody.