Why Humanising LLM Outputs Is Counterproductive for Agent Workflows

Human‑focused output styles compress agent work and lose information

Human‑oriented output formats such as Simplified Technical English (STE) or short‑sentence prompts force the model to compress its internal reasoning into a lower‑bandwidth representation.

  • Compression is lossy: details are dropped even if the text still reads smoothly.
  • Agents need the most information‑dense representation to solve tasks, preserve abstractions, and avoid breaking things.
  • Applying style constraints as part of the core instruction set mixes presentation with problem‑solving, unlike traditional systems where storage and display are separate layers.

"If you tell an agent to use short sentences, avoid jargon, never overwhelm you and only include the most important details, you are asking it to continuously compress its output into a lower‑bandwidth format. That compression is lossy." – kuberwastaken, Humanising LLM Outputs is Dumb

Raw agent output is essential for correctness and debugging

When agents communicate with sub‑agents, each layer should exchange exact, machine‑readable data:

5/6 PASS
FAIL: test_cache_invalidation
CAUSE: stale key survives restart
REPRO: tests/cache_test.py:184

A human‑friendly summary such as "Most tests passed, although there was one issue worth looking into" hides the precise failure information needed for automated remediation.

  • Detailed logs expose conflicting evidence, unresolved branches, stack traces, and uncertain assumptions.
  • Human prose tends to smooth over these signals, making it harder to detect hallucinations or subtle bugs.

Existing system design patterns keep fidelity until the boundary

  • Databases store raw rows; dashboards format them for users.
  • Compilers keep an intermediate representation (IR) that is not meant for human consumption.
  • APIs exchange structured data, not narrative summaries.

LLM tooling is increasingly reversing this pattern by forcing human‑readable formatting during the reasoning phase.

Accessibility and personalization belong at the final rendering stage

The author clarifies that the argument is not against making outputs accessible:

"If you want three‑line answers or Simplified Technical English, great! I just think it’s better to do it at the end."

The recommendation is to keep agents' internal state, schemas, diffs, confidence scores, and provenance intact, then transform the result for human consumption only once.

Community perspectives on the trade‑off

  • Xcelerate notes that after long LLM outputs they prompt a second pass to "decompress any LLM‑speak" for personal use, preserving raw output for future agents.
  • 7402 shares a prompt that suppresses friendliness and first‑person language, aiming for concise, factual answers.
  • Animats warns that forcing a style can introduce hallucinations, not just drop information.
  • firefoxd observes that search queries phrased like robot commands used to yield better results, but AI‑generated overviews have eroded that power.
  • pholden points out that output‑style settings in Claude affect only the main conversation; sub‑agents retain their own system prompts, so style leakage is limited.
  • boredumb argues that frontier models should prioritize machine‑level precision, leaving UI developers to build the human‑friendly layers they need.
  • TheCapeGreek and TheCapeGreek (duplicate) emphasize that many users actually want the lossy compression to avoid verbose commentary in code reviews.
  • wren6991 counters that LLMs already code‑switch internally (e.g., chain‑of‑thought vs. final output), so providing a simpler dialect for humans is not inherently harmful.
  • virajk_31 and scotty79 suggest a dedicated liaison agent that translates between machine‑optimal output and user‑friendly rendering.

Practical recommendation: separate the “thinking” and “talking” phases

  1. Keep the core agent output raw – preserve full test logs, error traces, confidence metrics, and structured diffs.
  2. Define a post‑processing step – after the agent finishes, invoke a formatter or a secondary LLM that translates the raw data into the desired human style (e.g., STE, concise bullet points).
  3. Expose the raw data via APIs – allow downstream tools or human reviewers to request the unfiltered output when needed.
  4. Treat style as a renderer, not an instruction – similar to how a database query returns rows and a UI component formats them.

By adhering to this separation, developers retain the fidelity required for reliable automation while still delivering accessible, personalized summaries to end users.

The discussion reflects a broader shift in AI tooling: moving from monolithic, human‑centric prompts toward layered architectures where machines communicate in precise, machine‑friendly languages, and only the final layer translates that into human‑readable form.

Sources

Related