Done Is Not Delivered: The Missing Leg in Agent Workflows

While building this system, I saw completed results wait inside the system instead of reaching the person who asked for them.

The failure came after execution. The system had treated a saved result as if someone had received it.

That mistake is easy to make in agent workflows. We spend most of our design time on execution. We ask whether the right model ran, whether tools worked, and whether the answer passed review. Then we place “done” at the end of the diagram. A Practical Architecture for Reliable Multi-Agent Systems shows where delivery belongs in the larger request path.

In a multi-agent system, “done” may only mean that one component has finished its part. The result can still be sitting inside a private task, a response file, or a callback queue. Delivery is a separate leg of the workflow.

This article focuses on that final leg.

Five states that look like completion

The easiest way to see the problem is to separate five events that often get collapsed into one.

These states build on each other, but they are not interchangeable.

Execution answers, “Did someone do the work?” Owner acceptance answers, “Did the accountable role stand behind the answer?” A callback answers, “Did the result return to the next responsible component?” Delivery answers, “Did it reach its intended destination?”

Natural product proof asks the hardest question: “Did this help in the real workflow?”

A completed result can still be stranded

Consider a weekly research brief produced by several agents.

A public entry point receives the request and passes it to a semantic owner. That owner asks a private specialist to review source material. A temporary worker then drafts the brief. The specialist and worker finish on time.

The semantic owner checks their work, fixes a weak claim, and approves the final brief. The request runtime records a completed result. So far, every execution metric looks healthy.

Now imagine the final response is written to a file. The system records the root request as complete. A dashboard turns green.

But the public entry point never receives a callback. It does not know that the owner-approved brief is ready. The requester sees only the earlier acknowledgement that work began.

The work is complete, but it is not delivered.

There is another version of the same failure. The callback reaches the public entry point, which records its receipt. Yet the tool that normally sends a message to the requester is unavailable. The callback succeeded, but the human still has no brief.

This is why I no longer treat a response file or callback receipt as evidence of delivery. Each proves something useful. Neither proves the final handoff.

Owner acceptance belongs before delivery

It may seem simpler to let any worker send its result straight to the requester. That can reduce latency, but it also removes a vital checkpoint.

In this system, the semantic owner is accountable for the meaning of the result. A specialist provides focused evidence. A temporary worker performs one focused part of the work. Their outputs are inputs to the owner, not automatic final answers.

That distinction matters when several workers disagree. It also matters when an answer is technically correct but poorly matched to the request. Someone must decide what to include, what to qualify, and what the system can honestly claim.

Owner acceptance is that decision.

Once the owner approves the result, the delivery path should preserve it. A transport or relay component can move the message. It should not quietly rewrite the conclusion or make a new domain decision along the way.

This gives us a clean responsibility chain:

worker execution
  -> semantic owner review and acceptance
  -> explicit callback to the public entry point
  -> requester delivery
  -> evidence of the handoff

Each arrow represents an obligation. If one fails, the system should say which one failed.

A callback is a return path, not a delivery receipt

Callbacks solve a real problem in asynchronous work. The original caller should not need to stay open while a long task runs. Instead, the system records where the result must return and creates an explicit request when the work becomes terminal.

The callback carries the result back to the role that owns the next decision. In our case, that was often the public entry point responsible for requester return.

This is stronger than placing a file in a shared directory and hoping another component notices it. An explicit callback has an identity, a destination, and a recorded outcome. It can be retried or inspected without guessing which file belongs to which request.

Still, a callback is only an internal handoff.

The receiving component must accept it. Then it must deliver the owner-approved message through the channel the requester actually uses. That may be a native task message, an API response, an email, or a governed relay through a visible caller.

If the preferred channel is unavailable, the system should record a degraded delivery state. It may use an approved fallback, but it should not call native delivery proven when a relay performed the handoff.

One fallback is to retain the initiating process for one exact request. It watches only that request’s identity, returns one terminal public result when it arrives, or closes with an immutable degraded receipt when it cannot. This is a narrow bridge for a caller that cannot expose a visible return address. It is not permission to poll the system broadly or retry the semantic job.

Honest state names are not decoration. They keep an operational shortcut from becoming a false product claim.

Delivery needs its own evidence

Good delivery evidence should answer three simple questions:

• What approved result was sent?
• Who or what was the intended recipient?
• What event shows the handoff occurred?

The exact receipt will depend on the product. It might be a message identifier, an acknowledged API response, or a record from a governed relay. The important part is that it belongs to the delivery step.

A worker completion timestamp is not enough. A saved artifact path is not enough. A terminal callback receipt is not enough. Those records describe earlier parts of the chain.

Delivery evidence also makes recovery safer. If a requester says the answer never arrived, an operator can inspect the boundary that failed. There is less temptation to rerun the research, create duplicate work, or overwrite a good result.

This does add state. The system must retain requester metadata, callback lineage, delivery posture, and a compact receipt. There are more transitions to monitor and more chances for old and new routes to drift apart.

That cost is worthwhile when work is long-running, crosses persistent owners, or must reach a person after the original caller has moved on. For a small synchronous answer in one conversation, a separate delivery service may be needless machinery.

Reliable Agent Work Needs Tickets, Locks, and Recovery explains how the system preserves the request identity and safe return path behind those delivery options.

A receipt still does not prove usefulness

Delivery receipts create another tempting green light. If the message reached the requester, it is easy to say the product worked.

That claim goes too far.

A receipt proves that the handoff happened. It does not prove the requester read the result, trusted it, or used it. It does not prove the brief arrived before the decision it was meant to support. It certainly does not prove that the workflow will remain useful across repeated runs.

That higher standard is natural product proof. It comes from representative work under normal conditions, with evidence that the result had the intended value. The evidence might include a decision made from the brief, a downstream process that consumed it successfully, or repeated use over time.

Even then, the claim should stay modest. One useful run does not guarantee every future run.

I think of these checks as a ladder. Routing proof is below callback proof. Callback proof is below delivery. Delivery is below natural usefulness. For a fuller version, see The Proof Ladder for AI Systems.

Put the requester back at the end of the diagram

Many workflow diagrams end at “final output.” That label hides too much.

For any asynchronous agent workflow, I now ask a few extra questions. Who approves the answer? Where does the approved result return? Which component owns the final handoff? What receipt proves that handoff? What evidence would show the product was actually useful?

Those questions do not make the model smarter. They make the system more honest about where work can fail.

Execution matters. Owner acceptance matters. Callbacks matter. But the requester cannot use a result that never arrives.

Done is an internal state. Delivered is a completed obligation.