Workflow and handoff testing
between tools, agents and approval steps.
Workflow and handoff testing covers what happens between tools, agents and approval steps, where failures hide. It matters when each step passes on its own and the workflow still does the wrong thing.
The real question
What is lost, repeated or assumed each time the work changes hands.
Step 02 of 05 · AI & Agent Quality
The loop
From scenario
to release decision.
Five steps, each feeding the next. This page is one of them.
- Agent evaluations
- Workflow and handoff testing (this page)
- Deterministic checks
- Evaluation harnesses
- Release criteria
Running exampleAn illustration, not a case study.
A support agent is asked to refund a duplicated charge. The refund needs an approval. The test checks that the action approved is the action executed, and what the agent does when the payment tool times out halfway.
01Questions
The questions
it answers.
Where are the handoffs in the workflow?
Every handoff is listed, whether a tool call, an agent-to-agent pass or an approval step, with what each side sends and what the other expects.
What survives a handoff, and what is dropped?
You know which constraints, identifiers and completed steps must reach the next agent, and each is checked on arrival, not assumed.
What does the workflow do when a step fails?
Each tool error, timeout, empty result and partial result has a defined response, whether retry, reroute, stop or escalate, and repeated runs show it.
Does the approval cover the action that runs?
The action executed is the one the approver saw, and a rejection, an edit and a timeout each have a tested result.
02Pitfalls
Where it
usually breaks.
Tool output obeyed as an instruction
A page, email or document returned by a tool carries text addressed to the agent. Nothing at that handoff separates data from instruction, and no scenario plants one to find out.
Tool errors read as answers
The tool’s wrapper catches the timeout and hands the model an empty result. The model reads “nothing found”, carries on and reports the task done.
Retries that repeat a consequential action
A refund goes through, the response times out, and the retry refunds the charge a second time. No test catches it, because in tests the tool always answers first time.
Approval tested only on the yes path
Approval is tested. Rejection, an edit, a timeout and a plan that changes after approval are not, so the control is unproven in the cases it exists for.
03Approach
How I work
on it.
Map every handoff and its contract
With your team I list each tool call, agent handoff and approval step, and write down what is sent, what is expected and what happens on failure.
Break each handoff on purpose
I inject a fault at each handoff, in front of the real tool or agent, and repeat each case: an agent’s response to the same fault varies from run to run.
Record what crossed and what ran
I keep a trace of every run: what crossed each handoff and which actions ran, so the handoff and approval checks have a record to assert on.
What you leave with
- A map of every tool call, agent handoff and approval step: what is sent, what is expected and what happens on failure.
- Failure-path and recovery runs for each handoff: error, timeout, empty result, partial result and retry.
- Tests for approval handling and the boundary around each consequential action: approval, rejection, edit and timeout.
- A trace per run of what crossed each handoff and which actions ran, for the handoff and approval checks to assert on.
04Measures
What I
would measure.
Signals to read, not targets to hit: what counts as good enough is your team’s decision.
Recovery rate under injected faults
A fall after a model or prompt change, measured over repeated trials, means recovery regressed even where the normal path still passes.
Executed actions that differ from the approval
A rise means approvals bind less of what runs; each mismatch is a control that failed, not a drop in quality.
Handoffs that arrive with something missing
A rise means constraints or identifiers are dropped between steps; the next step fills the gap with a guess, and the guess reads as a finished task.
05Evidence
The topic,
in practice.
From my employment and a business of my own: evaluations of AI features and a non-AI booking chain. Neither covers agent-to-agent handoffs or approval steps.
Case studies
Making AI evaluations trustworthy at an AI-native language-technology platform.
Dashboards on live customer data showed the success rate of each part of an agentic system’s user journeys, so the parts with low success rates could be improved and covered.
Ventures of my own
City Dreams
Not an AI workflow. I ran the checkout end to end against live reservations in test mode and rehearsed the failures: a declined card and a mid-checkout reload.
Need credible verification
of an AI workflow?
Describe the workflow, what it is meant to achieve and where confidence is thin.