A practical framework for deciding when an AI agent should assist, when workflow automation should run, and where a human must retain authority.

The question is not whether an AI agent is smart enough.

The question is: what is the smallest safe authority we can give this step?

Start with draft, classify and flag uncertainty. Do not send, change, approve or spend unless that authority has been explicitly designed and assigned.

Teams rarely fail with AI because they picked the wrong model. They fail because nobody decided who—or what—is responsible for each part of the work. An agent can research, draft, classify, recommend and sometimes act. A workflow can reliably move information, create records and execute a pre-approved rule. Neither has an implicit employment contract. Neither understands local judgement unless a team has made that judgement explicit.

The PathPatron Agent Handoff Map is a practical technique for deciding, step by step, whether work should be delegated to an agent, automated as a structured action, or kept human-led. It is not a maturity score and it does not ask a team to automate everything. It makes authority, escalation and ownership visible before a prototype turns into normal work.

A running example: a delayed-delivery refund request

A customer writes: “My order was late. I need a refund.”

It sounds like one task. It is not. It is a chain of different tasks with different levels of judgement:

Automation can create the ticket, pull the order number and route it to the right queue.
An agent can read the approved policy and order history, summarise the case, draft a reply and flag missing or conflicting information.
A human service owner should decide whether to grant a goodwill exception, change a customer commitment or issue a refund outside the policy.

That division is the point. The agent is useful; the automation is useful; the human remains accountable. The handoff map stops “AI triage” becoming a vague bucket in which nobody owns the consequential decision.

Start with the work, not the agent

Before selecting a tool, map the current work in plain language. What triggers it? What information enters? Which step applies a stable rule? Which step makes an interpretation? Where does the output go? What happens when the information is incomplete?

This is the Compass Process check. It protects teams from automating the most visible step while ignoring hand-offs, decision rights and failure modes around it.

In the refund case, the trigger is a customer request. The inputs are the message, order history and the current returns policy. Routing a complete ticket is a stable rule. Interpreting an unusual circumstance is not. Sending a policy-consistent status update may be pre-approved; creating a new promise to a customer is a decision.

For a practical discovery method, see The Transformable Process: Turning Pain Into Value. Where the workflow itself is unclear, use Map the Work Before You Automate It before selecting a tool.

The PathPatron Handoff Map

For each meaningful step, record eight fields:

Trigger — what starts this step?
Allowed inputs — which systems, documents and data may be used; under which access identity; and what must be logged?
Operating mode — agent, automation or human-led?
Allowed action — what may the system actually do: draft, classify, route, send, change or approve?
Human decision right — who may approve, challenge, override or stop it?
Escalation trigger — what uncertainty, impact or exception must reach a person?
Final owner — who is accountable for the outcome?
Feedback and maintenance owner — who updates sources, tests changes and monitors performance?

This is deliberately lightweight. It is enough to make a workflow discussable by the people who use it, lead it and carry the consequences.

The five handoff questions

Use these questions before you assign a mode:

Is the task bounded, repeatable and understandable from permitted inputs?
What can go wrong—and could the outcome create customer harm, financial loss, a legal problem, an unfair result or an irreversible action?
Who has authority to make, challenge or stop the decision?
What is the recovery path if the system is uncertain, wrong or operating on outdated information?
Does this mode improve the outcome or capacity enough to justify its cost and control load?

The answers do not produce a single “AI yes/no.” They help a team choose the right authority for each step.

Delegate to an agent

Delegate when the task requires interpretation across variable but controlled information, while the output remains reviewable or reversible and a human route exists.

In the refund case, an agent can read the request, approved policy and order data. It can prepare a concise case summary, identify whether the delivery date is disputed and draft a response in the right tone. It should be able to say “I do not have enough information” rather than filling a gap with a confident guess.

Delegation is not abandonment. The agent needs a task definition, allowed sources, no-go areas, completion criteria and an explicit uncertainty route. It may prepare a decision; it does not silently inherit the authority to make one.

Automate a structured step

Use automation where the work follows stable rules. Routing a form, creating a record, checking that mandatory fields exist, notifying an owner or executing a human-approved action are all strong candidates.

In the refund case, automation can create the ticket, attach order data and assign it to the correct queue. Once a human has approved a refund, automation can record that approval and issue the agreed credit. This distinction matters: automation can execute a decision that has been made. It should not invent the decision because a field happens to look complete.

Automation is often better than an agent when predictability, traceability and explainability matter more than open-ended reasoning.

Keep the work human-led

Keep human control when the work requires accountable judgement, empathy, negotiation, interpretation of ambiguous evidence or an irreversible consequence.

In the refund case, a human decides whether an unusual personal circumstance warrants an exception, whether a customer relationship needs a different response, or whether the team should change its policy. AI can surface evidence and alternatives. The human remains responsible for the decision and the promise made.

Human-led does not mean technology-free—or automatically better. Human decisions still need clear criteria, relevant evidence and a way to challenge inconsistency. It means technology supports judgement rather than disguising who owns it.

Make authority visible

A useful map for the refund workflow could look like this:

Ticket creation: automation; action limited to create and route; escalation if order data is missing; service operations owns the flow.
Case preparation: agent; action limited to summarise, draft and flag uncertainty; escalation if policy and case facts conflict; service lead owns output quality.
Refund decision: human-led; action limited to an authorised service owner; escalation above a defined value or outside policy; customer-service manager owns the outcome.
Approved refund execution: automation; action limited to the recorded approval; escalation if the execution fails; finance operations owns the recovery path.

The useful design is often not “agent or automation.” It is an authority sequence: automation → agent → human decision → automation. Each mode does the part it is actually authorised to do.

This is more useful than asking whether the agent is “smart enough.” It asks whether the organisation has designed a safe, valuable handoff.

Review is a design choice

“Human in the loop” is not enough. A reviewer needs time, context and authority to disagree. They need to know what good output looks like and what to do when the system is uncertain or wrong. Otherwise review becomes ceremonial sign-off.

For the service team, that means the agent must flag ambiguity before a draft reaches the customer. The human needs the underlying facts, not just the agent’s recommendation. The queue needs enough capacity for exceptions. And the team needs a record of what was approved, overridden and escalated.

The Agent Handoff Map assigns the decision boundary. The Review Loop shows how quality checking and escalation work in practice.

Before go-live: test the handoff, not only the output

Before expanding permissions, test representative normal cases, missing information, exceptions and policy conflicts. Check that the escalation reaches a named person, that the person can override or stop the workflow, and that the recovery path works when a system or source fails.

This is not a substitute for legal, security or risk review where the context requires one. It is the operating check that makes those boundaries usable in day-to-day work.

Use it before scale—and revisit it after change

At pilot stage, map the handoffs before celebrating a successful demo. A prototype can work beautifully while hiding the real operating questions: who owns source quality, trains users, responds to failures, approves changes and maintains the workflow after launch?

Return to the map whenever a new data source, action permission, customer channel or owner is added. A handoff that is appropriate for drafting may not be appropriate once the agent can send, change or approve. The maintenance owner should test those changes, monitor exceptions and make sure the approved knowledge stays current.

That is the PathPatron stance: useful AI is not a capability claim. It is an operating decision with a named authority, a recovery path and a person who remains accountable.

Navigating the Black Box Continuum: AI Agents vs. Automation
The Transformable Process: Turning Pain Into Value
Map the Work Before You Automate It
The Review Loop: Where Humans Must Stay in AI-Enabled Workflows — forthcoming
Decision Rights and Human Review: Designing Accountable AI Workflows — forthcoming
Operating Ownership After the Pilot — forthcoming