Stop on the First Schema Error: Why Halting Beats Retrying in LLM Orchestration

Implementation workloads started producing repeated invalid_json and invalid_schema errors. The tempting responses were all one click away: retry the call, split the task, bump the token limit.

None of them happened. The unit of work stopped on the first error. This post is about why that stop is the strongest move when you orchestrate models — and about the conditions under which it is not.

The incident

The pipeline: a planner delegating bounded implementation work to sub-agents, each task with a self-contained brief, a fixed model per role, and an exact file allowlist. The provider was experimental, and the workload was real: multi-file implementation, the kind of task where a malformed response is not an edge case but a recurring condition of iteration.

Under that load, the errors repeated: invalid_json and invalid_schema, again and again, even after reducing the scope of the tasks. The risk I logged at the time: auto-retrying, subdividing the work, or raising max_tokens would mask the cause and waste budget while degrading verification quality.

It is worth slowing down on that phrase, “degrading verification quality,” because it is not obvious.

Why retry is the wrong first response

A schema error is not a coin flip. It is a signal about the task-model fit.

When a model returns malformed output for a task, the most common causes are structural: the brief overflows what the model can hold coherently, the task’s shape does not fit the model’s strengths, or the load sits in the wrong layer of your pipeline. An automatic retry keeps the request exactly as it was — same brief, same shape, same model — and asks for a different outcome anyway. Sometimes you get one. A lucky parse is worse than a clean failure, because it ends the incident while leaving the cause untouched.

The budget side is just as real. Every retry is paid, and under sustained load the retries compound into a second invoice next to the work you meant to buy.

And there is a third cost, quieter than the other two: retries bury the evidence. The failure log that would tell you the brief is too large, or the task is in the wrong layer, gets overwritten by the next attempt’s outcome. Diagnose the first failure and you fix the pipeline. Retry it away and you rent a temporary success at the price of not knowing anything.

The stop, operationalized

The documented rule from that pipeline, nearly verbatim: stop the unit on the first schema or parse error. Retry, subdivide, and token-limit changes are not first-line responses to malformed output.

In that pipeline, the stop was concrete, not a shrug:

• The unit halted at the first error. No automatic retry, no subdivision, no max_tokens adjustment.
• The error was preserved: the documented protocol records finish_reason, usage, and a sanitized sample of the response when the provider delivers them — and reports it literally when they don’t.
• The brief was reopened with the failure visible. The next move is a human decision: rewrite the brief, re-scope the unit, change models, or approve one controlled experiment.

One boundary deserves its own line: a stop is not the same as a ban on retries. A single retry as a deliberate, human-approved experiment is legitimate — the protocol allows a max_tokens change exactly that way. What the rule removes is the automatic retry: the loop that fires without a diagnosis, whose success would erase the failure it just papered over. If a manual retry succeeds, record it as an experiment whose result does not prove causality, and keep the stop rule intact.

The general rule

Anyone orchestrating models can use this. The first line of defense against malformed output is not a retry loop; it is a stop condition.

• Treat schema and parse errors as stop conditions for the unit of work, not as transients to ride out.
• Preserve the error: finish reason, usage, sanitized response sample. The failure is data.
• Escalate to a human with the failure visible. The corrective moves — re-brief, re-scope, different model — are human decisions, because they change the shape of the work.
• Before the next unit of work starts, make sure the failure condition is addressed. Otherwise the stop bought you nothing.

The pattern behind the rule: an automatic retry optimizes for closing the incident; a stop optimizes for understanding it. Orchestration systems that survive are the ones that understand their failures.

When this rule does not apply

The stop rule earns its keep where failures repeat. Other regimes:

• For a flaky transport — timeouts, connection resets, 5xx from a gateway — a bounded retry with backoff is standard and correct. The stop rule is for malformed output, not for network weather. (A gateway timeout did appear in that pipeline, as its own error class, and it also stopped the unit — for orchestration-grade flows, stopping on infrastructure errors too is the stricter and defensible reading.)
• If you have not seen the failure before, one manual retry with full logging is a legitimate probe. The rule targets the second unexamined attempt, not the first observed failure.
• If your stack is a single user-facing chat call, a polite “please respond with valid JSON” recovery loop is fine. Nobody needs an incident protocol to render one chat bubble.

And one honest limit from the source itself: this evidence comes from one pipeline’s documented logs. The rule is a design decision validated by use, not a benchmark. Measure your own stop rates before treating the numbers as universal.

Epilogue

The experimental provider behind those errors was eventually removed, and the protocol documents remain as historical reference. The correction outlived the provider: stop on the first schema error, preserve the evidence, put the next move in human hands.

This incident is documented with its correction and learned rule in the Agent Systems case file. Its pair, on the other direction of the same lesson — proving that work happened before believing a green status — is Agent READY, usage 0%.