The correct-looking file: why AI agents fail and what experts offer

I have learned from the failures related to what agents produce when asked to do knowledge work, because they are the ones a grader passes and a user ships.

• A spreadsheet that comes back with every number being right. Every cell that should have held a formula holds a hardcoded number. It passed the value check. The next time anyone changed an input, nothing moved. Other failure modes include hardcoded constants where formulas belong, broken absolute references, circular references, ranges bounded so tightly that new rows do not flow, numbers typed into titles and prose that go stale three edits later.
• A deck came back with a beautiful waterfall chart. It was eleven rectangles and four arrows. Edit Data opened nothing. A market-sizing deck came back citing three sources in the chat message. The file carried none of them. One of the three did not contain the figure. Other failure modes include overflow, collisions, off-slide elements, slide masters bypassed with free-floating text boxes, hardcoded colors instead of theme references, page numbers typed as text, titles that label instead of conclusions.
• A document with a stale table of contents, tracked changes left in, heading hierarchy broken, terminology drifting across a long file, and corruption that accumulates across a multi-turn edit session.

They are not peculiar to files. When Parlance Labs ran six automated eval tools and coding agents against a hundred hand-labeled production traces from a leasing assistant, the best caught 87% of the failures (opens in a new tab), and every one of them missed the same class: responses that looked correct and failed the product's goal.

Part 1 (opens in a new tab) of this series argued that a wrong grader is a gradient pushed thousands of times. Part 2 (opens in a new tab) helps you to design training exercises for AI agents. Part 3 (opens in a new tab) discussed ways a grader lies in AI post-training: rubrics, answer keys and judges. This one is about what the output gets wrong, and who notices.

The failure taxonomy, compressed

Across a few hundred failure modes, coded from expert feedback and from probe suites run against three different implementation approaches, the same spine shows up in every file type.

• Validity. The file will not open. A file can pass every schema validator and a round-trip through an open-source office suite and still be refused by the application people use. Validity is not openability.
• Fidelity. Content silently lost. Numbers that drift from the source. Chart data labels that contradict the values underneath them. Facts and citations that were never checked.
• Collateral damage. Out-of-scope edits: a theme swap, a slide reorder, margin changes, edits to slides nobody mentioned. This is the enterprise complaint no public benchmark isolates, and it is invisible unless you diff against the before-file.
• Instruction adherence. Length, scope, template, exclusions. Placeholders left unresolved, or worse, placeholders filled with invented numbers when the brief said to leave them blank, an example that failed on every run of every model reviewed.
• Behavior. Claiming success on a broken file. Never reopening the output. Explaining instead of doing.

Two findings that cut across all of it: grading weight should follow severity, not frequency

• Correctness was the smallest class of defects in the expert feedback and carried most of the "unusable" verdicts; and
• Friction (permission prompts, latency) annoys people and barely moves their score. A wrong number moves it a lot.

OpenAI's misalignment reporting framework (opens in a new tab) has file-shaped examples from its own training runs: a model fabricating figures after a tool call failed, and one uploading local files to a public host to satisfy a citation requirement.

What experts see that graders do not

I have worked in consulting producing and reviewing several thousand output artifacts. What an expert catches: wrong methodology behind a correct-looking model. A chart that is the wrong chart for the claim. Whether the title states the conclusion or just names the topic. Whether the deck could be re-themed, which comes down to real placeholders versus typed footers. Whether the numbers tie to the source. And, most often, the difference between "this needs a light edit" and "I would start over," which no rubric I have seen captures.

That gap is what people mean by taste, and it can be written down.

• For a deck: conclusion-first titles, one message per slide, native and editable objects, theme-consistent color and fonts, the right chart for the comparison, sources on the slide, no overloaded copy.
• For a spreadsheet: formulas not constants, inputs visually distinct from calculations, ranges with headroom, no numbers typed into prose, an audit trail.
• For a document: heading hierarchy, a current table of contents, no placeholders, consistent terminology, tracked-changes hygiene, and changes confined to what was asked.

Written down, it becomes a rubric. Which brings you back to Part 3 (opens in a new tab), and the reason the expert must stay in the loop: a rubric is a snapshot of taste, and taste is the thing the graders cannot audit themselves. The operational definition we landed on is simple. Taste, for an evaluation, is the agreement between the eval score and a blinded expert ranking. Track it over time with a standing panel, and the panel's edit history becomes the reference answer.

The review itself must be designed.

• Blind: rank before any score is shown, with model names withheld and attempts shuffled.
• Two tracks: judge the brief first, then the output, so a good output cannot rescue a bad exercise. Every score with a one-line reason, or it is not saved.

Lilian Weng's piece on high-quality human data (opens in a new tab) covers the rater-agreement mechanics; the GDPval (opens in a new tab) team's decision to grade by blinded expert comparison, with the automated grader offered as a convenience rather than the answer, is the same conclusion reached independently.

Experts are expensive, so use them where they disagree with the machine. Thinking Machines Lab and Bridgewater found that vendor-supplied non-expert labels were often wrong (opens in a new tab) on financial triage tasks; they trained a model on the noisy labels, routed only the disagreements to experts, and cleaned the set that way.

OpenAI's CriticGPT (opens in a new tab) work points the same direction from the other side: a model-written critique made human reviewers better, not redundant. The annotation rules Husain and Shankar give product teams in their error-discovery guide (opens in a new tab) apply almost unchanged to file review: describe the problem so a colleague could act on it, do not root-cause, stop at the first upstream error, and read at least ten yourself before letting the agent suggest any.

What pre-training cannot teach

The model that comes out of pre-training already knows how to write a deck script. Watching traces of agents building decks, the mechanism is stable across runs: it writes code against a library, it uses native charts, it follows whatever scaffold it was given. Knowledge is not the gap. LIMA (opens in a new tab) argued that almost everything a model knows comes from pre-training and alignment mostly teaches format and behavior. Document work bears that out, with a specific list of behaviors the corpus does not carry.

• Closing the loop: reopen, render, look, before claiming success.
• Scope discipline: touch only what was asked.
• Native-object preference: a real chart over a picture of one, even when they look identical.
• Theme indirection: placeholders and color references instead of hardcoded values.
• Provenance in the artifact: the source on the slide, never fabricated.
• Multi-turn preservation: cumulative edits without content quietly disappearing, and
• Conclusion-first framing: the thing experts recognize instantly, and text corpora almost never label.

Every one of those must be taught by exercises paired with a before-file, a protected-content list, a known answer where one exists, and graders that can see collateral damage and hardcoding. A single artifact in a corpus exposes none of them. That is what post-training data is for, and it is why the strongest exercises are edit-and-revise rather than build-from-scratch. Editing is where the damage becomes measurable.

Anthropic's alignment team has written about the general version of this, that explaining reasons generalizes better than rules (opens in a new tab) and that small, targeted datasets can drive large behavioral change. The document-work version is narrower and more concrete: the model needs to be shown, many times, with a grader watching, that a file it did not check is a file it did not finish.

One tap

The cheapest honest measure of whether any of this is working is not a benchmark. It is one question at download: would you send this without opening it?

----

Daljeet Saran (dsaran@motifplatforms.com) is the founder of Motif Platforms, where he builds AI and data systems for commercial teams. He currently spends most of his time on pre- and post-training data and evaluation for AI agents that do real knowledge work.

Part 1 of this series: Reward hacking explained: how one bad grader teaches AI a thousand bad lessons (opens in a new tab). Part 2: How to design training exercises for AI agents (opens in a new tab). Part 3: Ten ways a grader lies in AI post-training: rubrics, answer keys and judges (opens in a new tab).