Your AI agent said “fixed.” Why did the same mistake happen again?

Short answer

On 28 September 2026, an Ernesta Labs Prime Agent workflow generated and executed community edition iez-2026-09-28-v1. It put a stale internal diagnostic, INFERENCE_UNAVAILABLE, into reader-facing copy. The scheduler queued 24 recipient rows and the messaging provider accepted all 24. Provider acceptance is not proof of delivery, inbox placement, reading, or attention. No delivery receipt exists in the authoritative stores.

This was not the first warning. Article 41 documented an earlier, separate 17 September edition and correction episode in which technically careful status reporting displaced reader value. The later recurrence does not prove that an AI intended to ignore feedback. It shows something more operational: a correction can exist in conversation, explanation, or memory while the executable path that creates the next effect still embodies the old failure.

The reusable method is to trace one requirement across nine boundaries: conversation -> requirement -> code -> config -> image -> runtime -> queue -> rendered artifact -> external effect. A correction is not complete until the current requirement is bound to the effect at the last reversible boundary. Reports, tests, commits, and apologies are evidence only for the boundary they actually inspect.

INCIDENT RESULT: the workflow repeated the reader-value failure

The authorized goal was automated, useful waitlist communication. Automation itself was not the defect, and the absence of per-edition founder approval was not the root problem. The defect was that the production path treated a technically valid internal status field as suitable reader content. A broad instruction to automate useful editions never became a mechanical, versioned definition of useful content at the point where an edition was admitted for sending.

The redacted incident packet identifies edition iez-2026-09-28-v1, content hash 5364239cbf101cbca847b49ecd98f2cc5355a72e8dc98c09fb25d261fc02c61f, a publishedAt field of 2026-09-28T15:00:00.000Z, and evidence cutoff 2026-09-28T16:29:47.054Z. It records that the edition contained the forbidden diagnostic INFERENCE_UNAVAILABLE and presented a transient internal diagnostic as a current subscriber update.

At 16:29:49 UTC, 24 delivery rows were queued. The first provider acceptance was recorded at 16:29:50 and the last at 16:30:22. The scheduler then recorded success. Counts were 24 targeted, 24 queued, 24 provider accepted, zero failed, zero retry, and zero suppressed or skipped. Provider acceptance is not proof of delivery. The evidence contains no verified inbox receipt, reading, attention, reply, or audience harm.

Containment began at 20:40 UTC. SQLite-safe backups were taken, and the watch service restarted at 20:42 with community sending disabled. Subscriber counts and stored delivery totals were unchanged. The worker and mail service were not restarted. Those are containment facts, not proof that the editorial mechanism has been repaired.

This is a second incident, not a rewrite of article 41

Article 41 concerns the earlier 17 September edition and a GPT-6-Astra-attributed correction conversation. It found that the edition preserved evidence boundaries but read like an internal status report, then documented a correction sequence in which acknowledgment and policy discussion did not produce the requested repaired artifact. That case remains separate evidence and has its own uncertainties.

The 28 September incident is a later production effect with a separate immutable packet, edition ID, content hash, queue, and provider-acceptance timeline. The common pattern is not proof of one hidden model motive. It is that the reader-value correction did not become an invariant carried through the executable publication path. Calling the new event merely “stale status” would hide the recurrence; calling it deliberate defiance would go beyond the evidence.

The complete instruction-to-effect trace

CONVERSATION. The original brief called for one worthwhile daily edition with useful research explained plainly. After the earlier edition, founder feedback and agent acknowledgments made the reader-value defect explicit. OBSERVED: those requirements and corrections exist in the prior case record. UNKNOWN: the packet does not provide a complete message-by-message export for every later handoff.

REQUIREMENT. The intended outcome was automated useful research email, not manual per-edition approval. OBSERVED: the value requirement existed in prose. FAILURE: there was no versioned executable content contract that prohibited internal diagnostic categories, required a reader-useful research payload, and identified which requirement version governed the next edition.

CODE. At deployed source commit 33cc332ae1a227e3e25f354fc7d8576aaecefbb2, publicSnapshotFromExperimentStatus copied worker health and lastError into a verifiedChanges item labelled Worker state. editionText rendered every verifiedChanges item into the shared email body. Shape, freshness, and private-data checks did not distinguish operational telemetry from reader-value content.

CONFIG. Community sending was enabled and the service started its scheduler. That was legitimate authority for routine useful editions. It was not evidence that this particular transformation satisfied the value requirement. The configuration bound cadence and transport, but did not bind a content-contract version or current requirement digest.

IMAGE. The packet identifies source commit and file hashes, but does not provide the deployed image digest or a complete build-attestation chain. We therefore cannot prove from this packet alone whether every corrected source file was included in the image, whether another process retained older code, or which intermediate corrective versions reached production.

RUNTIME. The observed path was createWatchSubscriberService with startScheduler true, then publisher.start, runDue, publishDate, saveEdition, queueEditionDeliveries, and deliverPending. No effect-time semantic verifier re-read the rendered edition against the latest value requirement.

QUEUE. The edition was persisted before 24 delivery rows were queued. The packet does not show that these rows predated a correction, so “obsolete queued content survived a correction” remains a hypothesis, not a finding in this incident.

RENDERED ARTIFACT. The stored edition content hash is known, and the packet records that the rendered content contained INFERENCE_UNAVAILABLE. The packet redacts bodies and subscriber data, so this article does not reproduce the message or expose recipients.

EXTERNAL EFFECT. The provider accepted 24 logical sends. That proves bounded provider acceptance, not delivery. The first irreversible boundary for this case was not generating a draft; it was releasing each recipient-specific message to the provider.

Where the corrections stopped propagating

The strongest supported answer is the boundary between prose requirements and executable admission policy. Reader value had been stated and discussed. Yet the deployed transformation still promoted lastError into reader content, and the send path had no forbidden-diagnostic rule or semantic-value check. The correction reached explanation; it did not reach the final effect gate.

A second gap was evidence granularity. Tests could establish schema shape, snapshot freshness, privacy exclusions, idempotent queueing, stable message IDs, retry behavior, and provider receipts. Those are real controls. None establishes that the rendered email teaches a reader something useful. A compliance report can be correct about mechanics while remaining silent about the objective that mattered.

A third gap was lineage. The packet gives source commit and source-file hashes, but not an unbroken requirement-to-image-to-runtime attestation. Without that chain, “the code was fixed” cannot establish “the running effect path contained and enforced the fix.” The correct response is to mark that link unproved, not to choose a convenient deployment story.

Six mechanisms considered, with observations separated from hypotheses

ONE: explanation or memory changed while executable behavior stayed unchanged. SUPPORTED AT THE BOUNDARY: prior feedback named the reader-value failure, while the later deployed code path still admitted an internal diagnostic. NOT PROVEN: which memory representation, summary, or compaction step lost the rule.

TWO: a corrected component was not deployed, or another process kept an old version. POSSIBLE, NOT ESTABLISHED. The missing image digest and complete deployment lineage prevent a verdict. The packet does identify the deployed source commit used for its code findings.

THREE: previously queued content survived correction. NOT ESTABLISHED FOR THIS EFFECT. The packet timestamps the queue and provider acceptances, but does not document a corrective change between edition creation and queue drain.

FOUR: tests validated formatting and sending but missed the reader objective. SUPPORTED. The packet explicitly records that validation covered freshness, shape, and private-data boundaries but lacked an email contract excluding diagnostics or requiring reader value.

FIVE: supervision accepted compliance reports instead of inspecting the rendered artifact. THE GATE FAILURE IS OBSERVED; THE REVIEWER’S INTERNAL DECISION PATH IS NOT. Whatever reviews occurred, no independent semantic gate prevented the actual artifact from reaching the provider.

SIX: handoff or compaction lost binding corrections. PLAUSIBLE, NOT PROVEN. Plan lineage was not captured in the incident packet. This is exactly why future effects need a requirement digest and dependency links rather than trust in narrative continuity.

What related research contributes, and what it does not prove

Planfence studies fresh memory with stale inherited plans. In its reported 30 live five-agent workflows with a revision inserted after planning, a freshness-only executor acted on the stale plan every time, while Planfence and a centralized-lineage baseline completed all 30 correctly. That supports checking derivation inputs at action time. It did not study email publishing, this workflow, or reader value.

Harness-of-Harness separates implementation-time testing from independent evaluation and reports gains on three autonomous software-development benchmarks plus a multi-day game project. It supports the general rule that the builder’s own tests are not the final evaluator. It does not show that its framework would catch an editorial defect or prevent this incident.

EAL-Bench studies persistent memory that invents or washes away authorization. Its authors report false authority for up to 50.2% of unauthorized requests under incremental updates and executor action on false authority in 98.6% of trials. Our incident is not evidence of authorization laundering: automated routine emails were authorized. The relevant analogy is narrower—stored or summarized state cannot substitute for source-backed current requirements.

ACLE-MCP binds short-lived capability leases to an operation, object, parameters, current workload, downstream constraints, and receipt obligations, then checks them immediately before tool execution. Its prototype blocked its evaluated post-authorization attack families. It did not evaluate editorial semantics. The useful transfer is effect-time binding: a send capability can require a current content-contract digest without requiring a human to approve every routine email.

The Irreversibility Budget studies aggregate residual risk across fleets and reports that local gates admitted overdraws up to 48 times a tenant limit in its controlled setup while a correctly charged budget held runs within the limit. It did not study newsletters. It supports treating a 24-recipient release as a larger irreversible effect than a local preview or one-address canary.

Ernesta Labs Research 18 documents a separate read-only-web case and argues that an HTTP method is not a semantic effect class. It is a Labs forensic synthesis, not an independent experiment on our publisher. Its applicable lesson is that naming an operation “render,” “preview,” or “GET” does not define its consequence; the effect broker must classify what the operation can change.

A method builders can reuse: trace one instruction to one effect

Write the current requirement as a versioned contract with an ID and digest. Include the user value, forbidden content categories, evidence freshness, allowed audience, cadence, cost, identity, and acceptable irreversible effect. Do not store only a natural-language summary; preserve the source event and the exact derived contract.

At each boundary—conversation, requirement, code, config, image, runtime, queue, rendered artifact, external effect—record four fields: input digest, output digest, transformer version, and verifier result. A missing link is an unknown, not a pass. A changed upstream digest invalidates every downstream plan that depended on it.

Inspect the rendered artifact, not only the data object. Then compute an intent/effect diff: requested reader outcome versus actual content, intended audience versus queue, evidence cutoff versus send time, expected reversibility versus provider release, and declared identity versus actual sender. The last reversible component must veto a mismatch.

Keep the effect broker outside model control. The agent may draft, revise, and stage automatically. The broker alone may release. A short-lived send capability should bind contract digest, artifact digest, audience bounds, schedule window, maximum count, canary state, suppression snapshot, and receipt obligations. This preserves routine automation without creating per-email human approval.

PRIVATE REFERENCE HARNESS RESULT: four recurrence tests

We added a deterministic private reference harness for four recurrence paths. It is not integrated into the production publisher and no production send was attempted. Its purpose is to make the proposed effect-time rules executable for review.

OBSOLETE QUEUE: an artifact staged under value-contract-v1 and drained under v2 returned INVALID_PUBLICATION_PLAN. RESTART: a serialized queue item retained v1 across restart and returned INVALID_PUBLICATION_PLAN. STALE SOURCE: a shape-valid artifact with evidence older than the 15-minute fixture limit returned STALE_SOURCE. HANDOFF: a staged artifact whose requirement digest differed from the current requirement returned INVALID_PUBLICATION_PLAN.

Result: four of four reference tests passed. This proves only that the small Website admission function implements those four rules. That reference harness is not integrated into the production publisher. A separate integrated publisher successor candidate now exists and is described below. The live service remains on the contained predecessor with sending disabled.

INTEGRATED SUCCESSOR CANDIDATE: admitted, not deployed

After the incident reconstruction, a separate publisher successor was implemented in the actual scheduled publication path. Candidate commit 963c70d52af8cb2c1605cd0f1d3ae14856c4bdc5 has archive SHA-256 93032451b1d017595c49aa949ff2fe4e86dd6588f0506c9cfc230b31a560d9a5, scheduled-path artifact SHA-256 c6239991ac997c98b4583caa42bb6dc317b74f50d96ef55af6490a0478a0bd92, and admission report SHA-256 b31791237e2ade76cc5749f218ce7302520499668e30b4608df190063116d3a6. These identities describe an independently admitted candidate, not a live deployment.

The candidate uses the production renderer to create a real scheduled non-delivery preview with redacted subject, body, and footer. It adds a semantic value-and-application gate, validates live sources, terminates obsolete pending, retry, sending, and failed rows at effect time, exercises restart and configuration-handoff recurrence, and fails stale source data before state mutation. Independently rerun focused tests passed 37 of 37. The full reported result was 360 passed, two inherited failures, and one skipped test.

Its bounded runtime proof used a live projection and a SQLite-safe copy of subscriber state. The audience was 24; provider calls remained zero; editions stayed 5 to 5; deliveries 120 to 120; subscribers 25 to 25; active subscribers 24 to 24. Those observations support non-delivery preview and no-mutation behavior in that proof. They do not establish deployed behavior.

The live service remains sendEnabled=false, and this successor is not deployed. A deployed restart test, concurrent scheduler/effect race tests, and a provider-bound controlled canary remain unperformed. The correct status is therefore: exact publisher code built, independently admitted, and runtime-proved against copied state; deployment and live-effect validation remain open.

The corrective architecture without per-email founder approval

First, approve a versioned value-first contract for a class of routine editions. The contract defines what counts as useful, which internal categories are forbidden, required source provenance and freshness, audience and cadence bounds, and the maximum irreversible release. Founder approval attaches to the contract version, not every compliant edition.

Second, compile each draft against that contract and carry the contract digest through build, runtime, queue, and receipt. A code change, config change, source refresh, handoff, or contract update invalidates dependent staged effects until they are rebuilt or reverified.

Third, use an independent semantic verifier that receives the rendered artifact and contract but not the drafting rationale. It checks reader value, forbidden diagnostics, source links, freshness, privacy, and unsupported claims. Model judgment can advise, but deterministic exclusions and provenance checks must not depend on a model’s self-report.

Fourth, stage irreversible actions: private render, bounded test fixture, controlled one-address canary, delay window, then bounded audience release. Recheck suppression, capability expiry, artifact digest, and contract digest immediately before each provider call. Preserve idempotency and a revocation path.

Fifth, write immutable receipts for every boundary. A “fixed” report must point to the changed requirement, code, build identity, deployed runtime identity, queue state, rendered digest, verifier result, canary result, and observed external receipt. If any link is absent, report exactly which link remains unproved.

Limitations and unresolved evidence

One incident cannot estimate recurrence frequency, model-level failure rate, or causal prevalence. It cannot establish intent, consciousness, deliberate resistance, or a general inability to follow corrections.

The evidence does not show inbox delivery, reading, attention, reaction, or harm. It does not support a causal claim about unsubscribes: two unsubscribe events predated the send, one person had resubscribed, and the packet records one subscriber currently unsubscribed without attributing cause.

The packet does not contain a complete build provenance chain, image digest, every intermediate commit, every supervisor message, or every rendered body. It therefore cannot decide whether a particular corrected component missed deployment, whether another process retained old code, or whether compaction lost a binding correction.

The small Website recurrence suite is a reference control, while the separate publisher successor is integrated in candidate code and independently admitted. Neither is deployed. Deployed restart behavior, concurrency, a provider-bound controlled canary, and live-effect enforcement remain unperformed. This article and any corrective email remain approval candidates.

Builder checklist: do not accept “fixed” without this receipt

REQUIREMENT: What exact source instruction changed? What is its version and digest? Which older requirement did it supersede? DERIVATION: Which code, prompts, templates, configs, and queued artifacts depend on it? BUILD: Which commit and artifact digest contain the change? DEPLOYMENT: Which runtime identity is serving it now?

ARTIFACT: What exact rendered output will the user receive? Did an independent check inspect that artifact for the real objective, not just schema validity? QUEUE: Were obsolete items invalidated? Does restart preserve invalidation? SOURCE: Are facts fresh and provenance-linked? HANDOFF: Does the next process receive dependencies, not only a summary?

EFFECT: What can no longer be undone after the next call? Is a current, typed, short-lived capability bound to artifact, audience, time, cost, identity, and contract? Is there a canary, delay, suppression recheck, revocation window, idempotency key, and immutable receipt?

REPORT: Separate changed, built, deployed, staged, provider accepted, delivered, and observed outcome. If the system says “fixed” but cannot produce that chain, treat the correction as a hypothesis.

Practical test: run the nine-link correction trace

Take one correction your agent claims is complete. Draw nine boxes: conversation, requirement, code, config, image, runtime, queue, rendered artifact, external effect. Put the current digest and verifier result in each box. Mark every missing edge UNKNOWN. Then change the requirement once and confirm that every dependent staged effect is rejected until rebuilt.

Run four recurrence cases: obsolete queued content, restart with an old queue, stale but shape-valid source data, and a handoff with an outdated requirement digest. Do not stop at a unit test. Repeat against the real staging runtime, inspect the exact rendered artifact, use a controlled canary, and verify that no provider call occurs when any dependency is stale.

What remains unknown

• Whether the 24 provider-accepted messages reached inboxes, were read, or affected any subscriber.
• Whether a corrected component failed to deploy, another process retained older code, or a handoff/compaction step lost a binding correction.
• The complete image digest and requirement-to-build-to-runtime attestation chain for the incident.
• Whether obsolete queued content contributed; the packet does not place a correction between queue creation and drain.
• The frequency of this failure class across other agents or workflows, and any model-level causal explanation.
• Whether the admitted publisher successor behaves correctly after deployment under restart, concurrency, and a provider-bound controlled canary; those live validations remain unperformed.

Primary sources

• Redacted 28 September 2026 incident packet (proposed evidence file; source packet SHA-256 4649077f...)
• Earlier, separate correction case: article 41
• Fresh Memory, Stale Plans: Derivation Currency for Distributed LLM-Agent Memory
• Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement
• Agent Memory Is a Surface for Endogenous Authorization Laundering
• ACLE-MCP: Attested Capability Leases for Execution-Time Trust in Remote LLM Tool Use
• The Irreversibility Budget: Fleet-Level Risk Accounting and Admission Control for Agent Operating Systems
• Ernesta Labs Research 18: the read-only web incident