Enterprise agents need a way to hand over the work

A company is bringing on a new supplier. Procurement has the completed form. Finance has the supporting documents. The agreement has been revised twice, and the one person who can approve an exception is away until Thursday. Everyone has done something, and nobody can say the supplier is ready.

This is the situation most enterprise agent projects walk into, and it is worth being clear about what the agents can and cannot fix. One agent can read the documents faster than a person. Another can compare the agreement with the approved template in seconds. Neither of those things moves the supplier through the process, because the process was never slow at the reading stage. It was slow at the joins: the point where one team's output becomes another team's input and something gets lost, repeated or quietly assumed.

Agentic orchestration is the work of designing those joins. It covers what happens next, what information travels with the task, and where the system has to stop and wait for a person. Microsoft's design guidance (opens in a new tab) treats it as an architecture problem rather than a prompting problem, and that framing is the right one. The question an enterprise should be asking is not how many agents it can run in parallel. It is whether anyone can trust what happens between them.

Follow the work, not the organisation chart

The first design we usually see proposed mirrors the company: a procurement agent, a finance agent, a legal agent, and a manager agent sitting above them. It feels natural and it is almost always wrong.

Separate agents are justified when they need different capabilities, different data or different permissions. If the only thing separating them is which department they are named after, every boundary you have drawn is a handover that can fail, a delay you have to account for, and one more place to look when the outcome is wrong. Very often a single agent with a well-chosen set of tools does the job with less to go wrong.

The distinction that actually matters in the supplier case is between work that follows a rule and work that needs interpretation. Checking whether a mandatory field is blank is a rule; nothing about it benefits from a language model. Reading an email that explains an unusual corporate structure, deciding which register to check it against, noticing that the explanation does not quite match the registration document: that is interpretation, and it is where an agent earns its cost. Anthropic's guide to building agents (opens in a new tab) draws the same line between workflows that follow a predefined path and agents that choose their own steps within granted authority, and recommends combining them rather than picking one.

So the supplier process keeps its fixed sequence of required checks. Inside a single stage, an agent is free to investigate a discrepancy however it sees fit. What it does not get is the ability to invent a new approval policy because a deadline is close. This also changes the opening conversation with the client. Instead of naming agents, we map what has to be true before the supplier can advance, and the architecture falls out of that list.

A handover must preserve uncertainty

Here is the failure that costs the most and shows up least in demos.

An agent notices that the company name on the onboarding form differs from the name on the signed agreement. It searches the correspondence and finds an email suggesting one is a trading name. That is good evidence. It is not a resolved discrepancy, and the difference between those two things is the whole problem.

A weak handover compresses the finding into "company details checked" and passes it on. The next stage, whether a person or another agent, has no way of knowing that a verification step has been replaced by a plausible explanation. A strong handover carries forward both names, the documents each came from, the proposed explanation, its source, and an explicit flag that confirmation is still outstanding. Whoever picks it up can see what was observed and what was inferred, and those are kept apart.

In practice the shared record for a supplier would look something like this:

Document collection

complete (6 of 6 received, last on 12 Oct)

Identity confirmation

pending. Name on form ("Harlow Fabrication") differs from agreement ("Harlow Industrial Ltd"). Email from supplier 13 Oct states trading name. Not yet verified against Companies House. Owner: K. Osei.

Contract review

not started. Blocked on identity confirmation.

Engineers call this state, and the point about state is that it has to live outside any one agent's conversation. Long-running orchestration needs a durable record with enough detail that a handover can be checked, not just a chat transcript that someone would have to read from the top.

The human payoff is concrete. The colleague covering for someone on leave does not have to reconstruct why a supplier is waiting. The supplier does not get the same question from three teams because each agent started from a partial view. And when the exception reaches the approver on Thursday, the thing they are approving is visible, not summarised.

Room to investigate, not permission to approve themselves

An agent may need to read every document a supplier has sent. It almost never needs to be able to change the approved-supplier record. Those are different permissions, and the gap between them should be enforced by the system, not by a sentence in the prompt asking the agent to behave.

Least privilege is an old principle and it applies cleanly here: the agent gets read access to a defined set of documents and the ability to prepare a proposed change, while a separate service checks authorisation before anything is applied. OWASP's agent security guidance (opens in a new tab) sets this out in more detail, and it is worth reading before deciding which tools an agent gets to call.

Supplier documents also have to stay evidence rather than becoming instructions. An attachment can contain text that tries to redirect the agent or persuade it to skip a check. That is prompt injection, and the realistic defence is layered: restrict tools, validate actions before they execute, and keep a person in the loop for anything consequential. No single filter should be treated as the answer.

The approval step itself deserves more design attention than it usually gets. The reviewer should see the specific discrepancy, the supporting documents and the exact action proposed. An "Approve" button beside a confident paragraph is not enough context to make a decision, and a reviewer who approves on that basis has not really reviewed anything. The approval should also be bound to the material that was actually looked at. If the supplier uploads a revised agreement while the request is in the queue, the earlier approval must not carry over silently to a document nobody has read.

Thursday still has to work

The approver returns on Thursday. The platform has been redeployed twice since Monday. One external registry service was down overnight. The supplier's progress should survive all of that without anyone noticing.

That means persistent checkpoints: storage that outlives the process, so the orchestration can resume after a restart rather than depending on a session having stayed open. LangChain's documentation on durable execution (opens in a new tab) describes the mechanism; the requirement is older than any framework. Completed checks stay recorded. Open items stay visible. A service that was unavailable is shown as a blocker, not quietly converted into a pass.

Before widening the system to more supplier types, test these cases on purpose: conflicting documents, missing information, tools that fail mid-task, and cases where the correct outcome is to stop and ask. Judge the result by what actually changed in the business system, not by whether the agent reported success. Anthropic's writing on agent evaluation (opens in a new tab) makes the point that a convincing account of success and a successful outcome are different things, and the gap between them is where production incidents live.

The measures we would track for this workflow are plain: onboardings completed correctly, discrepancies missed, unnecessary requests sent to suppliers, and the time reviewers spend on the exceptions that remain. That last one matters more than it looks. Moving work into an approval queue is not an improvement if every reviewer has to redo the investigation before they can decide.

Done well, the procurement team is left with a clear decision and the supplier with one coherent request for whatever is still missing. The agents have done useful work. More importantly, the people can tell where it stands.