What actually breaks when you run LLM agents unattended for 58 days

GX Cafe LLC — Fri, 21 Aug 2026 11:26:01 +0000

We run an organization made of agents. Not a demo — a company's back office. Bookkeeping,
inbox triage, drafting, review, research. 78 agents, local models, no human in the loop
between the schedule firing and the output landing in a ledger.

For 58 days we recorded every failure. Not "the run errored" — what was wrong with the
answer. 6768 records, published as a dataset.

This is what we found. It is not what we expected.

The uncomfortable part first: none of these raised an error

Every failure below returned HTTP 200. Every one had plausible length and fluent prose.
Every one was recorded by our monitoring as a successful completion.

On one day in this period our uptime metric read 97–100% for the full day, and the number
of finished deliverables was zero. Both numbers were correct.

If your dashboard says the agent ran, you have learned that the agent ran.

The distribution

Of the records that carry a stated reason, these are the types, by how often they occurred:

Count	Type	What it looks like
4875	`other`	`日本語が壊れている`
4054	`too_short`	`too short (0 chars, minimum 150)`
2535	`missing_required`	`missing required: 判定[:：]`
2330	`forbidden_present`	`あってはならないものが含まれる: (お客様/顧客)の声`
609	`broken_language_mix`	`Japanese and English mixed into nonsense (4 English function`
243	`chinese_in_japanese`	`Chinese characters in Japanese output: 资`
220	`answer_to_other_question`	`別の仕事の答え（採点用のJSON）が返ってきている`
172	`not_japanese`	`not Japanese (no kana at all)`
144	`unearned_claim`	`claims customers it does not have (ja)`
36	`refusal`	`断り文句で終わっている`
24	`reasoning_leaked`	`英語の思考が本文に漏れている`
9	`invented_specifics`	`材料に無い具体を書いている（readme.json, MIT）`

6589 of the 15251 type occurrences — 43% — are boring.

Not hallucination. Not jailbreaks. Not safety. The model answered — in the wrong shape.
It skipped the heading the downstream parser keys on. It wrote 0 characters. It answered
in the wrong language.

The dramatic failures everyone writes evals for — refusing (36), answering a different
question (220) — are the rarest things in the dataset. Combined they are 1.7%.

We had built our review pass around the dramatic ones.

Shape failures are the ones that cost you

missing_required is the largest single type, and it is the most expensive, because it is
the one that silently breaks a pipeline rather than one output.

Our single most frequent violation, 2535 occurrences, is one missing line:

missing required: 判定[:：]

判定 means "verdict". A review agent's contract requires a line starting with that word,
because a later stage reads that line to decide whether the reviewed item advances. The
model would write a thoughtful, correct, well-structured review, and put its verdict in
prose instead of on a line with that prefix.

The review is good. The reviewer is not wrong. The stage after it cannot read the answer.

This is what makes shape failures expensive: they are invisible to a human spot-check.
Someone reading the output sees a fine review and concludes the agent works.

A related failure, which we found separately and which the dataset does not contain:
42 items were approved by the upstream stage and produced zero downstream work. That one
was not a shape mismatch — the downstream stage was generating its input from four
hard-coded sentences and never read the upstream output at all. It had been that way from
the beginning. Both stages reported success for weeks.

Different cause, same shape of blindness: every stage was green, and nothing crossed
between them. We now record, on every produced artifact, which artifact it was made from,
so an unread output is visible as a number rather than as an absence.

Language corruption is invisible if you only read English

not_japanese (172) + chinese_in_japanese (243) + broken_language_mix (609) +
reasoning_leaked (24) = 1048 occurrences, our third-largest cluster.

Some samples, verbatim from the dataset:

Chinese characters in Japanese output: 资
Japanese and English mixed into nonsense (4 English function words inside Japanese)
not Japanese (no kana at all)

The last one is worth sitting with. In a model evaluation we ran while writing this — not
in the dataset, but with the same contracts we run in production — a candidate model
produced 1,680 characters of confident, well-formatted text for a Japanese review task
containing not a single kana character. It was entirely Chinese. Length: passed.
Structure: passed. A reader who does not read Japanese would see a completed deliverable.

If you operate in a non-English language, your base model's training-data language will
leak, and it will leak in a way that passes every structural check you have. We now measure
kana presence as a hard gate, and we keep the writer model and the reviewer model in
different families so a family-wide language failure cannot approve itself.

What we changed

Four things, in order of how much they mattered.

1. Declare the shape, machine-check it, before anything downstream reads it.
Minimum length, required patterns, forbidden patterns, expected language, and — for
anything with numbers — whether the number is labeled as measured, target, assumed, or
estimated. This is the tool we extracted from that work:
honto-contract. Zero dependencies,
synchronous, works on any string. It exists because we needed it, not the other way around.

2. When something fails, record why, not that.
For our first 41 days we wrote "contract not satisfied" and threw the reasons away. 1381 of
our 6768 records carry no reason, and we cannot reconstruct them — the outputs are gone. It
took us three weeks to notice, because "0 failures with a reason" and "0 failures" look
identical on a chart. Those 1381 rows are in the published dataset, labeled, because
deleting them would misrepresent what we know.

3. Do not let the writer approve its own work.
Our reviewer model shares no family with our writer model. When we briefly used the same
family for both, the reviewer approved six consecutive outputs that were in the wrong
language.

4. Measure produced output, not invocations.
We spent weeks judging "is this agent working?" by whether it had started recently. 78
agents were permanently excluded from remediation because a scheduler touched their
start-log every hour. The number was real. It measured the wrong thing.

The data

Dataset: GXCafe/ai-agent-failure-logs — CC-BY-4.0
Checker: honto-contract — MIT

Both are free. The dataset is one organization's records, not a benchmark: 6768 rows over 58
days from a single deployment, mostly Japanese-language tasks, mostly small local models
(7B–35B). It will not tell you what fails in your setup. It will tell you what kind of
thing fails when nobody is watching, which is the part we could not find written down
anywhere when we needed it.

We are still running. The dataset updates as we fail.

The rest of it

We keep running, so the dataset keeps growing, and the contract templates we use in
production (76 of them) are not in this repository.

If you want either of those, or you think the data is wrong, write to us:
sales@gxcafe.co.jp. We will tell you what we can and cannot do, in the same tone as
this page.

Notes on honesty

Every number here is counted from the published dataset and reproducible from it. Where we
do not know something, this article says so:

1381 of 6768 records have no stated reason. We started recording reasons on day 41. Recent days run about 78% with a reason. The gap is historical and we did not backfill it.
The type counts are occurrences, not rows; one failed output can carry several types.
We have no customers for this and are not claiming results from it. We built the checker for our own pipeline and published it because the failure taxonomy was the part we wished someone else had published first.

DEV Community: GX Cafe LLC