Designing human-AI handoffs: how to govern the boundary between agents and your team

Designing human-AI handoffs means making explicit, in advance, where agent work ends and human judgement begins. Most organisations have not done this. Agents are running — querying systems, generating outputs, routing decisions — but the handoff layer was never designed. Escalation happens informally. Accountability is assumed but unassigned. The result is unmanaged delegation: not a system, but an accident at scale. The fix is not about the agents themselves. It is about deliberately designing the boundary — the decision rights, the escalation rules, the verification gates that define how a hybrid team of humans and AI agents actually operates. That design is a leadership responsibility.

This article answers a single question: how do you design the handoff layer between AI agents and humans in day-to-day team operations?

The informal state most organisations are in

Most of the organisations I work with have agents running. A customer service bot handling tier-1 queries. A tool pulling competitor data on a schedule. An agent matching billing records against delivery. It mostly works. Occasionally something gets missed and someone catches it. Nobody designed the handoffs. They emerged.

This is not a criticism. It is a description of how most agent deployments begin: as a tool solving a specific problem, gradually doing more, until the informal handoffs between agent and human become the invisible architecture of how the work actually gets done.

The problem appears when something goes wrong. A decision gets made — or not made — and nobody is clear who should have owned it. The agent didn't flag it. The human assumed the agent had it. The gap was not a technical failure. It was an architectural one. The handoff was never designed.

The failure mode: unmanaged delegation

The problem is not agents. The problem is unmanaged delegation.

The handoff is the boundary design: where agent work ends and human authority begins. Delegation is the act of assigning agent authority over a step or decision. Escalation is the event of routing to human judgement. All three are part of the same governance design question.

Unmanaged delegation means agents doing work that shapes customer interactions, financial records, and competitive decisions — yet nobody explicitly assigned those responsibilities to them. When organisations add AI agents without designing the handoff layer, they are implicitly delegating to the agent decisions and outputs nobody explicitly assigned. Because it was never formalised, accountability for those decisions cannot be clearly assigned.

DeepMind's work on intelligent delegation makes this explicit: formal delegation requires authority, accountability, monitoring, trust levels, and verification rules. Remove any of those and the delegation is not managed: it is assumed.

Unmanaged delegation compounds. Add more agents and you add more informal handoffs. More outputs that humans are implicitly reviewing without a defined brief for what to look for. More decisions shaped by agent outputs that nobody is explicitly governing. This is shadow infrastructure: not a designed system, but a set of accidental dependencies that grow every time a new agent is deployed.

As agent deployments multiply, shadow infrastructure does not stay stable. It compounds. That is the consequence worth taking seriously before the architecture becomes hard to untangle.

The reframe: escalation is governance, not failure

Here is the distinction that matters most.

When a support chatbot is bolted onto a queue and escalates a query, that escalation is typically treated as a failure: the bot couldn't handle it. The escalation is a cost, a fallback, a sign the tool didn't work.

When you design a customer service process from scratch with a human-AI team, escalation is different. It is the system working correctly. The agent resolves what it is briefed to resolve. It escalates what it is briefed to escalate. The human owns complexity. The agent owns volume. The escalation path is a designed governance feature, not an improvised fallback.

This is the conceptual shift that separates organisations building an AI operating model from those bolting agents onto existing processes: escalation from an agent to a human is a governance feature when it was designed, and a liability when it was not.

The question is not "how do we reduce escalations?" It is "have we designed the escalation rules deliberately?"

How do you design human-AI handoffs? A three-part framework

Designing human-AI handoffs requires three things: mapping the workflow and handoffs, defining decision rights and autonomy levels, and building explicit escalation rules. Research on hybrid delegation and decision-making, including work published in ACM on human-in-the-loop systems, consistently identifies these as the core design requirements for effective human-AI coordination. That structure matches what I see in production deployments.

Map the workflow and handoffs in hybrid human-AI teams

Before you can design a handoff, you need to see it. That means mapping the workflow at the step level, not "the agent does the research" but "the agent queries these systems, structures findings into this format, and delivers output at this point in the process."

For each step, the design question is: who acts here, and who decides? Some steps are agent-only: execution, data retrieval, formatting. Some are human-only: strategic judgement, exception approval, rule governance. Some are hybrid: the agent surfaces structured options, the human chooses.

The third category is where most handoff failures live. Hybrid steps that were never explicitly designed default to whoever happens to be paying attention. That is not a handoff. It is an assumption.

The three worked examples below are drawn from Graph Digital's own production deployments.

Worked example — competitive monitoring: An agent queries competitor surfaces on a schedule, structures findings into a standard format, and flags changes against a materiality threshold. The handoff is explicit: agent delivers structured signal, human applies strategic judgement to that signal. The agent does the attention work: consistent, tireless, never misses an update. The human decides what to act on. Neither step bleeds into the other because the boundary was mapped first.

Define decision rights and autonomy levels for AI agents

Once you have mapped the handoffs, you need to define what the agent is and is not authorised to decide alone.

This is the AI delegation framework. It does not need to be complex. But it does need to be explicit. For each agent and each step, the question is: what level of autonomy does this agent have?

A working structure:

• Execute autonomously — Execute autonomously means the agent completes this step without any human review. Typical steps: querying a data source, formatting output.
• Execute and flag — Execute and flag means the agent completes the step and surfaces exceptions for human review. Work proceeds; anomalies are routed up.
• Recommend and wait — Recommend and wait means the agent generates output but takes no action until a human approves. The agent proposes; the human decides.
• Escalate immediately — Escalate immediately means the agent does not attempt resolution and routes the step directly to human judgement.

Most agents operate across multiple autonomy levels depending on the step. The design job is to assign the right level to each step, not assume the agent will work it out.

Worked example — financial reconciliation: In a billing reconciliation process, agents query CRM and project management systems, compare billing against delivery, and flag discrepancies. The autonomy levels are explicit: below a defined threshold, the agent auto-resolves; above the threshold, it produces an escalation summary for human review. The human reviews exceptions and approves the weekly report. The human also updates the threshold rules, governing the system rather than running the process. Decision rights for AI agents are not set-and-forget. Someone has to own the governance layer.

Design escalation rules and verification gates

Autonomy levels tell the agent what it can decide. Escalation rules tell it what to do when it cannot, or should not, decide alone.

Good escalation rules are specific. Not "escalate if unsure" but "escalate if the discrepancy exceeds £500" or "escalate if the query contains an emotionally charged phrase from this list" or "escalate if no resolution path matches within three steps."

A verification gate is a mandatory human review point in the workflow. Not because the agent is expected to fail, but because the output at that step has downstream consequences that warrant human sign-off before the process continues. Verification gates differ from escalation rules: they apply regardless of whether the agent flagged anything.

Microsoft's Azure AI Agent Orchestration Patterns document the multi-agent coordination layer in detail: how agents hand off to other agents. This framework sits above that layer, at the human boundary, where the agent system as a whole hands off to human judgement, and what the rules are for that transition.

Worked example — customer service routing: A tier-1 support agent resolves what it can against a knowledge base. Escalation rules are binary and designed in advance: if the query cannot be resolved, route to human. If the query matches an emotionally complex classification (frustration signals, formal complaint language, repeat contacts), route directly to human, not through the resolution logic. Every interaction is logged. The escalation is not a breakdown. It is the system doing exactly what it was designed to do.

Every deployed agent should have answers to three questions: What does it decide alone? What triggers an escalation? What produces a verification gate? If those answers are not documented, the handoff was not designed.

The AI Portfolio Review applies this three-part framework to your current agent deployments, mapping which have designed handoffs and which are running informally. Request the review

What leaders actually need to decide

This is not a question the IT team can answer on behalf of the business. It is a leadership question about how to operate.

The organisations I work with that do this well are not the ones with the most sophisticated technical architecture. They are the ones where leaders have explicitly answered questions that most leaders have left implicit:

• Which decisions are we willing to delegate to systems?
• What level of error is acceptable before human review is required?
• Who is accountable when outcomes are shaped by both people and agents?
• Who governs the threshold rules, and how often do we review them?

The checklist later in this article gives you a structured way to run this audit across your current deployments, one question per governance gap.

The shift required is not from managing people to managing AI. It is from managing people doing tasks to governing systems that support judgement. Hybrid human-AI teams demand more active leadership, not less. The autonomy of the agent does not reduce the leadership burden — it relocates it. Less time spent directing task execution. More time spent governing decision rights, reviewing escalation rules, and ensuring the audit trail is clean.

AI agents in marketing, sales, and customer success operations — some of the highest-volume deployment areas — make this especially visible. In these teams, handoffs show up in how agents route leads, prioritise accounts, and escalate at-risk customers to the humans who own the relationship. Commercial AI agents embedded in CRM and support platforms are doing real work that shapes real outcomes. The quality of the handoff design has direct commercial consequences.

The compounding problem

One agent deployment: the informal handoffs are manageable. Someone catches what slips through. The shadow infrastructure is small enough to be invisible.

Three deployments: the informality compounds. Different agents, different implicit rules, different assumptions about who is reviewing what. The humans catching things are catching more things, from more directions, with less visibility into what they are supposed to be looking for.

Five deployments: the organisation is running on shadow infrastructure. Agents are doing real work that shapes real outcomes. The handoffs were never designed. The accountability is diffuse. Adding the next agent makes it harder, not easier, to untangle.

This is not a hypothetical trajectory. It is the one I see repeatedly, at different scales, across different industries. The organisations that avoid it are the ones that treated the handoff layer as a design problem from the start.

Understanding what it means to become an agentic organisation is useful context here. The operational work of designing how humans and agents coordinate is the more immediate step.

Are your agent handoffs designed or assumed?

Before building a governance framework, the most useful question is simpler: can you answer, for each deployed agent, what is designed and what is assumed?

Run through your current agent deployments:

• Does each agent have a defined scope — what it decides alone, what it escalates, what it never touches without human review?
• Is there someone who owns the threshold and escalation rules, and can say when those rules were last reviewed?
• When an agent produces an output that shapes a commercial decision, is there a human review step, and does that human have a clear brief for what to look for?
• Do your agents produce audit trails: structured records of what was processed, what was escalated, and what the human decided at each exception?
• Can you say, for each deployed agent, what an undetected failure looks like, and whether your current governance would surface it?
• As you add the next agent, does the governance layer scale with it, or does it depend on the same informal human attention that is already stretched?

If several answers are "no" or "we haven't thought about it", the handoff layer was not designed. That is not a failure — it is simply the starting point.

Where to start

The first step is not a governance framework document. It is an honest map of what is already running.

Which agents are deployed? What are they doing? Where does their output go — and who is reviewing it, on what basis, with what brief? For each deployed agent: what does it decide alone, what triggers escalation, what produces a verification gate?

Most organisations find, in that mapping exercise, that the answers are informal, inconsistent, or not documented anywhere. That is shadow infrastructure made visible.

The AI Portfolio Review

The AI Portfolio Review is a structured diagnostic that maps your current agent deployments against the three-part framework: workflow and handoff mapping, decision rights and autonomy levels, escalation rules and verification gates.

For each deployed agent, it produces a clear assessment: designed handoff or informal delegation — where the gaps are, and what the governance priorities are. It is structured and time-boxed, not a programme commitment. The output is a clear governance priorities map: which of your current agent deployments have designed handoffs, and what the correction looks like for each.

If you have agents running and the handoff layer has not been designed, this is the right place to start.

Request an AI Portfolio Review