Skip to content

When an Agent's Report Needs the Work Behind It

When an AI agent's report uses names its reader cannot identify, a useful rewrite may need to recover their meaning from the underlying work, rather than just shorten the prose.

One AI agent in a new study cites a source as “R03.” An automated reader checking the reply cannot identify which paper it means. The example comes from a scripted project in an October 14 preprint, rather than a workplace conversation. It preserves a source label while losing the connection the recipient needs.

That distinction matters when someone delegates work they do not intend to watch. An agent can investigate a question or change some code while its requester does something else. On returning, that person needs to understand the result without reconstructing the investigation. A short name that helped the agent keep track may give its reader another puzzle to solve.

For a report containing such references, clarity can require recovering missing information as well as choosing better words. A rewrite may need to go back to sources, notes or results returned by its tools to discover what a name means and why it matters. This is a practical interpretation of the study’s results, not a measured benefit for people using agents at work.

What the reader already knows

A developer posting as ForSpareParts describes a related problem in Claude-generated code comments and descriptions of proposed code changes. The example packs together several programming references. Some, the poster says, are reasonable: colleagues would already know an important project-specific term. Other references send a thorough reader looking for definitions before they know whether those concepts matter to the explanation.

The complaint exposes a limit of asking for simpler English. A sentence can use familiar words while depending on decisions or results its reader has never encountered. Replacing long words does not identify those missing connections. Explaining every project term would create the opposite problem, burying the point under things the audience already understands.

The thread offers no universal prompt remedy. The poster reports partial improvement from a simplified-English standard; respondents describe success with templates, examples or configuration instructions. These are individual experiences, but their variation matters to the interpretation. The problem need not arise in every report, and an instruction that suits one team’s shared knowledge may suit another poorly.

Consider the audiences for a coding agent’s account. The person who supervised the session and a colleague reviewing the changes later can share technical expertise while knowing different parts of the work. The second reader may need an earlier choice explained even when the first does not. Useful brevity comes from selecting what this recipient needs, not merely selecting a smaller word count.

Giving the report a job of its own

The paper tests an automated reading check: does the reply answer the request, use the requester’s language and make necessary meanings recoverable? One unresolved gap can fail a reply.

At 256 selected reply points across 8 models, explicit reporting requirements lowered failures from 52% to 43%. A general audience notice produced no clear improvement. The requirements covered the answer, work, result, next step, evidence location and unfamiliar names. They were also placed differently, so content and placement were not isolated.

One plausible explanation is that audience awareness leaves the communication work unspecified. Knowing that a person has not seen the investigation still leaves the agent to identify what they asked, select the result and resolve the names needed to understand it. Concrete instructions spell out those operations. A different explanation is that instructions arriving just before the reply have more influence. The experiment leaves room for both.

These are results of an automated reading test in scripted projects, not a workplace failure rate. Nor does the comparison establish that every answer should have the same headings. A question about whether a test passed and a request to recommend a design give the report different jobs. The design recommendation may depend on explaining alternatives that a simple test result need not discuss.

What a second writer can recover

A secondary model given the request, draft and work record lowered the same failure rate to 36%. It could do more than edit the final message in isolation.

For a reference such as R03, that distinction is essential. Shortening the surrounding sentence cannot establish which paper it denotes. A writer with the relevant record can look for the connection. Without it, the writer needs to retrieve more information, ask for clarification or leave the uncertainty visible. A smoother sentence cannot supply a fact absent from its inputs.

An independently built tool makes that input choice tangible. Posting as Marium_noor, the author of Simplify Claude describes using Claude Code daily and wanting to know what changed and what might break after a session. Their extension offers a status-bar command that turns the session transcript into a plain-English account.

The reporting prompt asks for the goal, concrete changes, things to check and unfinished work. The transcript parser, however, keeps user and assistant text alongside shortened tool-call descriptions, excludes blocks containing the tools’ returned results and trims older material when necessary. This is an inspected implementation, not an effectiveness test.

Filtering is a reasonable design choice: less material can keep a writing pass focused. It also changes what the writer can recover. A note that a test command was invoked need not establish whether it passed. If the assistant’s text accurately preserves that outcome, the compact transcript may be enough. If the outcome disappeared with the tool output, the writer cannot reconstruct it from the command name alone.

That is a potential tradeoff, not an observed defect in the extension. It means a second writer’s access to evidence belongs in an evaluation alongside the quality of its prose. Adding another model does not by itself establish which missing connections it can restore.

Enough explanation to use the result

An understandable account need not absorb the whole record. Even the paper’s reader check excludes filename and path references, on the assumption that the recipient can open them. A useful report and a route to the underlying evidence can coexist.

They serve different needs. The account explains the result and the choices that matter now; the record lets someone pursue a disputed detail. For builders of agent interfaces, this suggests preserving a way for the reporting step to follow consequential references without requiring every recipient to read every tool output. Whether that reduces people’s effort remains a question for studies of their actual work.

The developer’s complaint also returns here: adding context indiscriminately can make an explanation harder to follow. A paper title identifies a source, but the relevant finding explains why it belongs in the answer. The reporting job is to recover the connection the recipient needs. Once that connection is clear, the reader can spend their attention deciding what to do with the work.

Sources

Understand How People and Agents Work Together.

Practical essays, experiments, and lessons from building software for people and agents.

Occasional emails, sent when there is something worth reading. Free to subscribe. Unsubscribe at any time.