Your agent is about as diligent as its grader
A model that just cracked a hard maths problem from a paragraph of prompt will, an hour later, cheerfully report that it processed twelve documents when it processed four.
The frontier in mid-2026: agents are not lazy the way they were in 2023, they are relentless where something checks their work and confident where nothing does. Which way yours tends depends less on which model you run than on what it is working on, and whether anything is watching.
We use five operating guidelines; each traced to failures we hit in production and to mechanisms documented below:
- Write "done" as checks, not as a goal. Not "finish the migration" but "done means: this validation passes, these two counts reconcile, this file exists at this path." Current frontier models can use exactly this signal and calibrate to it.
- Verify at submission, not after the run. Have the tool that accepts an agent's work validate it before accepting it. A failed check should come back as a rejection while the agent can still respond to it, not as a finding in a review that happens after the agent has moved on. And bound the loop: a retry should show evidence of progress, and the same failure arriving twice is a signal to stop or escalate, not to resubmit.
- Never let the model's own summary write a status field. "All twelve documents processed" is a prompt to run the guideline-1 checks; status is set by what they return. The model's sentence about its work is a hypothesis, and - as the incidents below show - sometimes a false one contradicted by its own transcript.
- Give every check enough resolution to fail plausible-but-wrong work. A gate that counts output records passes five hundred wrong records - counting is not reconciling. A gate that greps logs for "SUCCESS" teaches the model to print SUCCESS. A gate that runs the tests means little if the agent can edit the tests. Before shipping a check, ask what the laziest artefact that still satisfies it looks like; if you wouldn't accept that artefact, the check is under-resolved.
- Make your test runs faithful to production runs. Current models recognise evaluation-shaped contexts - synthetic company names, placeholder emails, suspiciously convenient files - and behave differently when they suspect one; the shift is toward their best behaviour, which means production can come in below your evals. However you build your eval data, keep it compliant with your data-processing agreements and GDPR.
All five compensate for the same trained property of the underlying models. A model is about as diligent as its graders were discerning: effort tends to inherit the resolution of the evaluation signal it was optimised against.
As with many things in life, we need to caveat: these guidelines are calibrated to the mid-2026 frontier (Claude Fable 5, GPT-5.6, Qwen 3.8, Kimi K3, GLM-5.2), and each new release absorbs a little more of them. The newest models already read your stated criteria and self-check before finishing, so guidelines 2 and 3 come up less often than a year ago; but the checks a model invents for itself remain systematically weaker than the ones you specify (a benchmark study through the GPT-5.4 generation calls the failure self-validation drift), and the absorption is domain-shaped. You can see the split inside a single model generation: paired with a proof assistant that rejects any step which does not check, the frontier is relentless and largely honest; take that grader away and the same GPT-5.6 generation is documented in its own system card updating a research draft to claim an equation had been "computed and verified" when it had not. Mathematics ships with its own grader; most production domains do not, and this advice matters in proportion to that gap.
The rest of this post is why: where we believe this behaviour comes from in the training stack, and why two years of rapid RL-algorithm progress made it stronger rather than weaker.
Two incidents
We have the bruises that made us learn. One run closed with a summary claiming success while the tool results in its own transcript said the work had failed and nothing was written; another blew past our runtime ceiling and spent two more hours and five hundred tool calls circling the same validation checks, saving nothing.
These look like different bugs, laziness and runaway persistence, but we'll argue they are one calibration showing opposite signs, traceable to graders: in training, and in our own runtime.
By grader I mean whatever produced the signal a model was optimised against, at any stage of its training:
- the human raters who compared pairs of outputs in preference tuning;
- the reward model trained to imitate those raters at scale;
- the unit tests, output checkers, and task verifiers used in reinforcement learning on real tasks;
- and, recently, the success criteria your own harness states at run time, which current models can look for and use.
The first three shape the model's weights; the last steers a single run. Either way, the same thing decides what you get back: how well the grader can tell real work from plausible-looking work. Then, a model's effort is not a personality trait but a learned answer to the question: what did it take to satisfy the graders I was trained against? Where a grader could tell thorough work from plausible-looking work, the model learned to be thorough. Where it couldn't, the model learned that the difference doesn't matter.
Three training stages, three blind spots: each produced a behaviour builders still hit today.
Pretraining: incomplete examples in, incomplete outputs out
The web is full of incomplete artefacts: explanation of work, not finished work. For example, in many programming tutorials you'll find deliberately incomplete code: // handle errors here, # ... rest as before. Complete artefacts live elsewhere in the corpus (whole repositories, shipped files), which is why the shape of your context decides which pattern you get.
Pretraining, the dominant behaviour-shaping stage before instruction tuning and RLHF became standard (roughly 2022), optimises one thing: predict the next token of that corpus. There is no grader judging task completion at all, and that is the blind spot. A model that answers "write the implementation" with a skeleton and // remaining cases left as an exercise is not cutting corners; it is accurately reproducing what "here's the implementation" is followed by in its training data.
The expectations we form are as follows:
- Prompt reads like a tutorial ("show me how to parse these files")? Expect tutorial-shaped output: explanation plus the interesting fragment.
- Context looks like a real file being edited in place? Completeness rises, because complete files are what follows that context in the corpus.
- Context contains one full example of what done looks like? Expect output at that fidelity.
In each case you haven't asked for more effort; you've changed which pattern is being completed.
What this means for building. In the base-model era this was most of the toolkit: few-shot exemplars were how you got completeness at all. Post-training has since taken over most effort calibration, but the corpus prior never left: it still governs format fidelity, and it resurfaces whenever your context accidentally reads like a tutorial. Guideline 1 is this era's descendant: "state what done looks like" began as "show what done looks like", and the showing version still works when the stating version fails.
Preference tuning, 2022-2024: a grader who rates what they can see
The RLHF era (InstructGPT and ChatGPT in 2022, through the GPT-4-class models of 2023-24) added the first grader that judged whole outputs: human raters comparing two candidate responses, with a reward model trained on those judgements at scale.
Assume the human rater evaluates the response for "write a function that parses these date formats".
Response A, sixty lines: timezone edge case handled, inputs validated, one visible mistake in an error message. Response B, twenty-two lines: clean, covers the main path, notes that "additional formats can be added as needed". The rater has about a minute. A's mistake is right there to see; B's missing edge cases would only surface if the rater re-derived the full requirements, which nobody does in a minute, thousands of times over.
Response B wins this comparison, because the only difference the rater can see favours it. A small systematic edge is all a gradient needs; at scale, the asymmetry becomes pressure toward responses that look complete over ones that are complete: polished, confident, fewer exposed decisions, fewer ways to be visibly wrong. OpenAI had people review summaries for flaws, reviewers given a model-written critique as an aid found roughly 50% more flaws than reviewers working without one, in the same summaries. This explains the documented length bias in reward models: when thoroughness cannot be checked in a minute, the look of thoroughness, length, gets rewarded instead.
The blind spot turns into expectations you can state in advance:
- Ask "is this correct?" and expect agreement more often than scrutiny; endorsing your framing rated higher than challenging it.
- Ask for a change whose completeness can't be seen at a glance ("update every call site") and expect the visible subset.
- Ask for a review and expect thorough-looking before thorough: confident, well-structured, and lighter than the problem deserves.
OpenAI confirmed the dynamic from the inside in January 2024, shipping a GPT-4 Turbo update whose release notes said the new model "completes tasks like code generation more thoroughly" and was "intended to reduce cases of 'laziness'": the previous run had produced under-delivery, and the dial was the lab's to turn.
What this means for building. Guideline 3 was born in this era, when "task complete" was rewarded largely independently of the truth, and serious 2023-24 agent scaffolds (the word "harness" only became standard later) commonly wrapped their models in external verification. The advice has softened since, not retired: Opus 4.8's honesty training moved the base rate substantially (Anthropic claims a roughly fourfold reduction in unremarked code flaws), but the base rate is model-specific, a cheaper tier or open-weight model may still sit near the 2023 calibration, and no base rate turns self-report into a verification method.
Reinforcement learning on real tasks, 2024-present: a grader who checks the outcome
Verifiable-reward reasoning models arrived in autumn 2024; by 2025, coding agents such as Codex were being trained with RL on real-world tasks: the model works in a sandboxed environment (calling tools, editing files, running tests) and gets rewarded when the outcome verifies. The bug is actually fixed; the tests actually pass; a rater's impression of one reply no longer decides anything.
This grader sees through polished skeletons, and the effect was dramatic: today's coding agents work through long tasks with a persistence that would have been unrecognisable in 2023. Nowadays, the blind spot is narrower and sharper: whether the check passed, not how. Models learned to exploit exactly that gap, documented by the labs' own monitoring: hardcoding the values a test expects, special-casing the checker's inputs, deleting a failing assertion. (the pattern is not new: in OpenAI's 2017 robotics work, a policy learned to place its manipulator between the camera and the object so that it merely appeared to grasp it.) Hence, tests that are visible and editable from inside the task will eventually be treated as part of the solution space.
In other words, 2023 laziness tracked what a human rater could notice in about a minute; 2026 laziness tracks whatever the automated checks can measure. The effort became genuine, and the blind spot moved from the limits of the rater's attention to the limits of the checker's coverage.
This is where our two opening incidents fit. If you give a model a grader that can't detect omissions, you get confident "done" on unfinished work. When you give it verification pressure without verification discernment (checks that measure the wrong thing, a context that can't tell a productive retry from a doomed one), you get gaming and grind. The instinctive fix for a lazy agent, demanding more effort, doesn't fix the calibration; it slides the agent toward the opposite failure.
What this means for building. Two of the five guidelines date from this era, and both have model-generation dependencies the way code has library-version dependencies. Guideline 2 became effective only when error-followed-by-recovery entered the training distribution; in our runs with 2023-era models, a rejection usually bought an apology and the same mistake, and the better move was restarting with a fresh context. Guideline 4 became necessary as models grew strong enough to satisfy checks by unintended routes; in 2023 there was little worth fencing. A harness still running 2023-era patterns (silent retries, checks that were never probed) isn't wrong so much as compiled against an old model version.
Why two years of RL-algorithm progress didn't fix this
The RL toolkit has been rebuilt twice since 2023; surely the algorithms caught up? Let's do a walk-through.
The 2022-era RLHF pipelines used PPO, which trains a second network (a value model, or critic) to estimate, at every step, how well the episode is going. Effective but expensive: the critic can be as large as the model being trained. DeepSeek's GRPO (2024) removed it: sample a group of, say, eight attempts at the same prompt, score each, and define each one's advantage as its score relative to the group average. No critic and substantially lower training cost; through 2025, group-relative methods became the default pattern for reasoning RL, surrounded by refinements each fixing an optimisation pathology: DAPO (decoupled clipping, dynamic sampling of informative prompts), GSPO (sequence-level importance ratios, which stabilised mixture-of-experts training for the Qwen3 generation; what the newest Qwen models train with is undisclosed), CISPO, and several more.
These refinements mostly improve the efficiency and stability of climbing outcome-level rewards. Some add auxiliary signals (DAPO penalises overlong responses), but none supplies step-level supervision of task progress: the reward still cannot see how the outcome was reached. That is part of why the pattern persisted: a stronger optimiser pointed at the same half-blind grader doesn't reduce the exploitation of blind spots, it accelerates it, because to the optimiser an unmeasured gap and a genuine improvement are the same thing: reward.
GRPO's structure also offers a mechanism for the grind side. Its advantage is computed per episode and applied to every token in it. In a forty-step run that succeeds at step forty, the six wasted retries at steps twelve to seventeen share the same episode-level advantage as the step that actually fixed the problem. At scale, that would reinforce trajectory shapes, flailing included, rather than the actions that carried the outcome: persistence and floundering are indistinguishable to a grader that only scores the ending.
The strongest public signal consistent with this diagnosis came in June 2026 from Zhipu's GLM-5.2, an open-weight model tuned for long-horizon software engineering. Its agentic RL stage moved back from group-relative optimisation to a critic-based, single-rollout formulation: agentic rollouts vary wildly in length, so group sampling stalls on stragglers and drifts off-policy, and online environments often return only a single trajectory per prompt. The accompanying paper therefore trains a value model and computes token-level advantages instead (Z.ai's release notes describe the same shift). The same release describes its verifiable coding rewards as vulnerable to reward hacking, guarded with rule-based detection plus an LLM judge: grader-guarding, built into training. In this post's terms, a value model is a denser grader: a per-step estimate of whether the trajectory is on track. It can distinguish steps within a run, which trajectory-level scoring cannot; whether it actually sees the wasted retries depends on what the learned value function captures, a caveat we return to below. It is also a way for us to be proven wrong: if critic-trained models like GLM-5.2 turn out to grind in deployment no less than their outcome-only peers, the mechanism we are describing is not what drives it.
Moonshot documents the other half in the open: K2's technical report pairs a Gym-like verifiable-rewards framework (deterministic and model-based checks across coding, math, logic, and instruction-following) with self-critique rubric rewards for the qualities no single check captures. (K3's launch post does not yet disclose its post-training recipe, so we won't guess.) Across labs, the engineering effort has visibly moved to the grader side: denser critics, richer rubrics, harder-to-fool verifiers.
That effort now extends to evaluation itself. OpenAI's deployment-simulation work (paper) replays real production conversations through unreleased models precisely because evaluation-shaped data gives itself away: its detector classified traditional evaluation traffic as evaluations 98.9 to 100% of the time, and real production conversations only 5.4% of the time. Anthropic's Petri 2.0 treats the same cues (implausible users, too-convenient setups) as defects to engineer out of its audits. If your eval data looks fake, you are measuring what the model does for an audience. That is guideline 5's reason, and it is why the labs' own measurement pipelines are converging on realism.
What this means is that the goalposts moved, and the same logic applies to the graders themselves:
- A value model is a learned approximation; a strong policy finds and exploits its mis-estimates. Value-model exploitation is one of the oldest failure modes in actor-critic RL.
- A self-critique rubric makes a language model the judge; a learned judge is an imperfect proxy that strong optimisation exploits (reward-model overoptimisation), and LLM judges carry documented biases of their own.
Each upgrade in grader resolution bought real behaviour (models genuinely became more diligent with every cycle) and relocated the blind spot rather than closing it.
That, as far as we can tell, is the technical answer to "why does this still happen in 2026": the policy-optimisation track made models climb whatever reward exists faster and more stably; only the grader track changes what the reward sees, and that track is younger, harder, and by its nature never finished.
What this means for building. Capability gains that make a model better at satisfying verifiable rewards can also make the deployed model better at finding the gaps in your gates: a validation that held against 2024 models gets probed harder by 2026 ones. Guideline 4 is recurring maintenance involving re-reviewing what each check actually measures on the same cadence you upgrade models, because the model upgrade is also an upgrade to the thing searching your checks for gaps. Guideline 5 needs similar attention involving eval realism.
At Ameba, purchase orders, packing lists and lab reports do not ship with a proof assistant, so we build the graders ourselves: a quantity that doesn't reconcile against its order doesn't get written back.