Imagine an AI agent preparing a supplier recommendation. A second agent checks the analysis. A manager receives a polished summary with two reassuring labels: complete and reviewed. But the delivery estimate came from an old quotation. The first agent noted that uncertainty in its working notes, and the second checked the math in the summary without ever seeing the note. Everyone performed the task they thought they’d been given, and the recommendation rests on an unresolved assumption.
This example exposes an organizational question that deserves more attention as work moves between people and AI agents: what, exactly, must be transferred before the next participant can responsibly continue? A finished answer is only part of that transfer. I’d argue that leaders need to define what travels with the work, so that “done” means the same thing to everyone.
What New Research Adds
A preprint posted November 2, 2026, Measuring AI Agents as Teammates with Collaborative Intelligence, tests AI models as teammates across 240 tasks, working alongside scripted and AI teammates. One finding is especially relevant: frontier models passed 97% of tasks they started themselves, but only 81% when they took over a task in which a weaker model had already cheated, for example on a coding test. Researchers also found that general capability explained much of a model’s teamwork score without guaranteeing good teamwork: models with nearly the same capability differed by up to 11 points. These are benchmark results from a controlled test, and they don’t estimate failure rates in real workplaces (arXiv: Measuring AI Agents as Teammates).
A different kind of evidence comes from OpenAI’s November 4, 2026 account of its autonomous security-research pipeline. In an early run, 20 of 200 apparently successful exploits had used a different vulnerability from the one assigned, and OpenAI added checks to confirm the system had done the assigned work (OpenAI: A thousand fewer paths to root; CSO Online, November 5, 2026). This is one developer’s report on its own engineering, so it says little about agent reliability in general.
Neither source proves that a particular management practice will solve the problem. Together, they give leaders a reason to test an assumption: does success at one stage actually establish what the next stage depends on?
Completion Has a Recipient
We often describe an AI workflow as a sequence of tasks: research, analyze, review, decide; but that says little about what makes the connection between tasks dependable. In the supplier example, the researcher might consider its job complete when it identifies the best option from the available information. The reviewer might interpret its role as checking whether the recommendation follows from the numbers. The manager might assume that “reviewed” means the underlying commercial terms are current. Those definitions can coexist unnoticed until someone acts.
The executive task is to make the dependency clear. If a decision depends on a current delivery commitment, the workflow must establish that commitment or visibly leave the decision open. A status label can’t stand in for the missing evidence.
[I made a related argument in Your AI Pilot Looks Finished. Would Anyone Tell You It Isn’t? A status label is only as useful as the shared understanding of what it means. Handoffs between AI agents make that understanding harder to keep, because no single person sees the whole chain of work.]
Every participant doesn’t need to repeat all the work. What the workflow needs is clarity about what has been established, what remains conditional, and who is responsible for resolving the condition.
Design the Handoff From the Receiving Side
A useful starting point is to ask the person responsible for the next significant step what they need to know before proceeding. For the supplier decision, that might include the original quotation, its date, the assumptions behind the comparison, and any terms awaiting confirmation. A reviewer should be able to tell a checked calculation from a checked source. The manager should be able to tell a recommendation from permission to commit funds.
I’d turn those needs into a brief acceptance rule for the handoff. It should specify the evidence that must accompany the work, the unresolved conditions that prevent further action, and the owner who can resolve an exception. Keep the rule tied to the decision. A routine internal summary may need only source links and a clear note about uncertainty. A purchasing commitment may require a current quotation and a named approver. More documentation is useful only when it improves the next participant’s ability to act.
The organization should also decide what happens when the receiving participant rejects the handoff. Does the work return to its originator? Does a person resolve the gap? Can the workflow pause without someone quietly changing “unconfirmed” to “good enough”? A handoff rule without a workable way to reject incomplete work creates pressure to accept it.
Give the Reviewer a Different Job
Adding a second agent may be useful, but calling it a reviewer doesn’t establish what it reviewed. Return to the hypothetical supplier recommendation. If both agents work from the same summary, they may agree because they share the same missing information, and their agreement gives the manager little assurance about the original quotation.
A more useful assignment would ask the second agent to compare the recommendation with the underlying records and identify which conclusions those records don’t support. The reviewer would report the checks it performed and any unresolved discrepancies, so the manager sees more than an endorsement of the final answer.
That still wouldn’t guarantee independent judgment. Agents may share assumptions or limitations even when they have different instructions, and a human reviewer can miss a problem too. The practical question is whether the additional stage catches meaningful errors that would otherwise pass through, at a cost the organization can justify.
At Whole Enterprise™, this is part of Intelligence Stewardship™: deciding how intelligence is brought together, challenged, and used. The business leader remains responsible for the decision standard. AI can help meet that standard, but it shouldn’t be allowed to redefine it silently.
Test the Connection Before Adding More Agents
Choose a bounded, non-production workflow with a clear outcome. Use a hypothetical case or appropriately protected historical material, and include a few known issues that should affect the result. For example, give the supplier exercise an outdated quotation, an unresolved delivery condition, and a recommendation that overstates the available evidence. These are deliberately planted test conditions and say nothing about any real supplier.
Run the current workflow first. Then repeat it with explicit handoff requirements and a reviewer who can inspect the relevant source material. Keep the cases comparable and examine the differences.
Count more than the number of objections. Did the workflow identify the important problem? Did it correct the recommendation or keep the decision open? Did it carry the issue through to the manager, or mention it in working notes and lose it in the final summary? Also record false alarms, review time, and the effort required to reach a defensible decision.
This is a local design experiment, and passing it won’t prove the workflow is ready for every case. It can show whether an additional review step contributes anything beyond a more reassuring presentation. A simple starting configuration is one agent that analyzes, another that challenges, and a person who decides between them; its value still has to show up in the resulting decision.
Keep Workflows Simple
Elaborate handoffs could make AI-enabled work slower and more cumbersome than the process it replaces, which is why the goal should be the smallest set of connections and checks that supports the business decision. Some tasks may work better with one capable agent and a clear human acceptance step. Others may benefit from specialized agents. An extra stage earns its place by improving an outcome, reducing a material risk, or making responsibility clearer. A diagram that looks more sophisticated with another box is no reason to keep one.
As models and tasks change, revisit that design. A safeguard that once mattered may become redundant, and a new type of work may introduce a dependency the existing process never checked.
Define “Done”
Leaders don’t need to inspect every exchange between agents. They do need to know what the organization means when a workflow reports that work is ready.
For one important process, ask the receiving decision-maker to complete this sentence:
“I can accept this work when these facts are established, these uncertainties are visible, and this person owns whatever remains unresolved.”
Then test whether the workflow actually delivers that. The handoff is where one participant’s work becomes another participant’s basis for action, and designing that connection is part of designing the job.
