Your Agent Isn't Done Until It Reports Back

Inside this article

An agent's job has four legs, not three: accept the work, do the work, verify the work, and report the outcome. Most harnesses build the first three and leave the fourth to chance.
The completion-to-communication gap is where production agents silently lose their value. The work happened. Nobody found out.
The fix is architectural, not a prompt tweak: capture the outcome at the source, package it as a durable event, and deliver it to whoever asked. Treat the report as part of the definition of done.

In the piece on the verify step, the failure mode was an agent claiming success on work it never did. The fix was to check reality before calling anything done. But there is a quieter failure mode one step later in the pipeline, and it costs more because everything went right until the very end: the agent accepted the work, did the work, verified the work, and then told no one.

The work completed. The outcome died in a log file.

The Four-Legged Job

Ask a team to describe an agent's job and you will usually get three stages: receive the request, execute it, confirm it worked. That model is so common it feels complete. It is not. A job is not done when the work is done. A job is done when the person who asked for the work knows what happened.

That makes four legs, and every one of them is load-bearing:

The four legs of an agent job shown as a pipeline: accept the request, execute the work, verify against ground truth, and report the outcome to the requester. The fourth leg is highlighted as the one most systems drop.

Accept. The agent receives the task with enough context to do it.
Execute. The agent does the work against real systems.
Verify. The harness checks ground truth before declaring success.
Report. The outcome reaches the requester in a form they can use.

Drop the fourth leg and you have built a very expensive machine for doing work nobody hears about.

The Gap Is Real, and It Is Expensive

This is not a theoretical risk. It is the default architecture of most agent systems, because each leg tends to be built by a different component with a different owner. The orchestrator accepts the task. A tool layer executes it. A verification pass confirms it. And the report back to the user is assumed to happen because, well, the function returned.

Here is what that assumption looks like in production. An outbound voice agent is asked to call a vendor and get an answer to a question. The dial works. The conversation works. The call log shows a clean "completed" status with a plausible duration. And the summary of what the vendor actually said arrives nowhere, because nothing in the system was responsible for carrying it from the voice session back to the chat where the request originated. Three legs of the job, engineered and observed. The fourth leg, missing entirely.

The operator experience in that system is worse than if the call had failed. A failure is actionable. A silent success sends the operator back to do the work by hand, except now they also distrust the automation. You have spent money on the call, spent the vendor's time on the conversation, and produced negative confidence.

Two timelines compared. In a fire-and-forget system the agent completes the task and the outcome evaporates, leaving the operator to redo the work. In a fire-and-report system the outcome travels back to the requester as a durable event.

Why "The Function Returned" Is Not a Report

The naive answer is that the agent framework already reports results: the tool call returns a value, the run completes, the status flips to done. That is a receipt, not a report. A receipt tells the system that something terminated. A report tells a human what happened, in their language, with the facts they asked for, where they are already looking.

The gap between the two is specific and engineerable. A real report-back has four properties:

It is captured at the source. The outcome is recorded while the work session is live, not reconstructed afterward from logs that may not exist. If your agent talks to someone, the transcript is captured from the stream, in the moment, because after hangup there is nothing to reconstruct.
It is packaged as an event, not a side effect. On terminal status, the harness builds a structured outcome object: what was asked, what happened, what was said, how long it took, what it cost. That object has a schema, and it is durable.
It is delivered to the origin. The outcome is routed back to the session, channel, or person that made the request, through the same push-based machinery the system already uses for every other kind of completion. Nobody should have to poll a log to learn their answer.
It degrades honestly. If the work failed, the report says so and says why. A system that reports only success trains its users to assume silence means success, which is the most dangerous default an agent platform can have.

The four properties of a real report-back drawn as a loop: capture at the source, package as an event, deliver to the origin, and degrade honestly, feeding back into the next request.

The Architecture Is Boring, and That Is the Point

None of this requires new science. It requires the same discipline applied to the fourth leg that teams already apply to the other three. The outcome object gets a contract. The delivery path gets a queue with retry. The requester gets a notification in the channel where they asked. Failure paths get the same coverage as success paths, because a system that can tell you "the call connected for 68 seconds and here is what was said" must also be able to tell you "the number did not pick up."

The report-back architecture drawn as a flow: the live work session streams into a transcript capture, which feeds an outcome builder on terminal status, which enqueues a delivery event routed to the originating session and user.

The pattern generalizes past voice. An agent that edits a pull request owes the reviewer a summary of what changed and why. An agent that reconciles a quote owes the rep the deltas, not a green checkmark. An agent that runs a nightly batch owes someone a diff against yesterday. In every case the work is only half the deliverable. The other half is the message.

What This Means for the Channel

For the IT channel buyers we work with, this is the difference between an agent deployment that gets renewed and one that gets quietly uninstalled. The demo impresses because the agent does the thing. Production disappoints because nobody can find out what the thing did. The operators stop asking the agent, then they stop trusting it, then the renewal conversation starts with "we are not really using it."

The fix is cheap relative to the cost of the platform around it. When you scope an agent deployment, put the report-back on the architecture diagram as a first-class component with an owner, a schema, and an SLA. Ask the vendor how outcomes reach the requester, in writing. If the answer is "check the dashboard," you have found the fourth leg missing before you signed, which is exactly when you want to find it.

An agent that cannot report back has not finished the job. It has just stopped working on it.