Let the model see the result
An agent needs observations it can inspect again, especially when its first explanation is wrong.
Design note
An agent acts on a world it does not see directly. A tool returns an observation, the model interprets it, and another action follows. The interface between observation and interpretation deserves as much attention as the prompt.
The useful question is not whether the model sees every byte. It is whether it can recover the evidence that would change its next decision.
An observation is not ground truth
A successful tool response can describe the wrong file, an old page, or a request that completed without achieving the intended effect. Passing it through unchanged preserves evidence. It does not guarantee that the evidence is accurate or sufficient.
Consider an illustrative task: update an application's configuration, then verify that the application uses it. The write tool reports success, but the response names a temporary copy of the configuration rather than the file the application loads.
A wrapper that reduces this to “Saved successfully” removes the detail needed to spot the mistake. An unedited thousand-line log preserves it, but may bury it. A useful result could lead with the resolved path, the operation performed, and the verification outcome, while keeping the original response available for inspection.
The problem is the loss of a decision-relevant distinction, not compression itself.
Keep the route back to the evidence
I would design the result interface around two layers: a compact observation for the current decision, and a stable reference to its underlying evidence.
The compact layer should say what was attempted, which target was affected, what was observed, and what remains unknown. The reference should let the agent retrieve the original material without repeating a potentially expensive or destructive action.
Pagination works well when the model needs to inspect a long output sequentially. Structured fields work well when the tool can state a result precisely. Summaries can help when their claims remain traceable to recoverable source material. None of these formats should silently turn an uncertain outcome into a successful one.
Choose the size of an action deliberately
Small tools make some failures easier to isolate. They also create more calls and more intermediate states to coordinate.
In the configuration example, separate read and write tools expose the steps. A single transactional edit tool could be better if it verifies the expected starting version and refuses to overwrite a concurrent change. Splitting that operation into smaller pieces might remove the very guarantee that makes it reliable.
The useful unit is an action with a clear contract, observable effects, and a comprehensible failure mode. Tool count is a consequence, not a quality measure.
Test recovery, not just completion
A comparison could hold the model and tasks fixed while varying the result representation: raw output, structured output with source references, or a summary alone. Deliberately return stale paths, partial successes, and conflicting observations.
Record task completion, unsupported conclusions, successful recovery, and the cost of fetching more detail. A shorter result is valuable if it saves attention without hiding the reason to change course.
The strongest interface may be the one that helps the agent discover that its previous interpretation was wrong.