The dirty secret of AI coding agents is that they lie. Not maliciously — they simply can't tell the difference between intending to write a file and actually writing it.
When you ask an LLM to create a new component, it has no feedback loop to confirm the file was actually written to disk. It assumes success and hallucinates the rest.
This creates three categories of hallucination:
1. Ghost Files
The model claims it created src/components/Button.tsx — but the file doesn't exist on your filesystem. You don't notice until your build breaks 20 minutes later.
2. Phantom Edits
The model says it "updated line 47 of config.ts to fix the timeout" — but the actual file is unchanged. The model hallucinated the edit based on what it thought the file contained.
3. Stale State
The model remembers the file from 5 turns ago, but you (or another tool) modified it since then. The model's "edit" is now based on outdated content, producing corrupted output.
Why This Happens
LLMs operate on token prediction, not filesystem state. When a model generates a FILE_ACTION block, it's predicting the most likely next tokens — not executing an operation. The model has no concept of "disk" or "inode." It lives entirely in the text stream.
AI failures are rarely intelligence issues. They are environment and execution issues. This is the core problem the Mythos Router solves.
Traditional AI coding tools work around this by: - Blindly writing whatever the model outputs (dangerous) - Asking the user to manually verify every change (tedious) - Hoping the model gets it right (cope)
| Approach | Hallucination Handling | Atomic Writes | User Friction |
|---|---|---|---|
| Generic Wrappers | Fails Silently | No | High |
| Mythos SWD | Auto-Correction Loop | Yes | Low |
None of these are engineering solutions. They're prayers.
The SWD Protocol
Strict Write Discipline (SWD) is a validation-first protocol that treats every file operation as a claim to be proven, not a command to be trusted. You can read the full specification on the System Architecture Reference page.
Here's how it works:
Step 1: The model wraps every file operation in a structured block:
[FILE_ACTION: src/utils.ts]
OPERATION: MODIFY
INTENT: MUTATE
CONTENT_HASH: sha256:a1b2c3...
DESCRIPTION: Added error handling to parseConfig
CONTENT: <full file content>
[/FILE_ACTION]Step 2: The SWD engine verifies the claim against the actual filesystem: - Does the file exist at that path? - Does the content hash match what was written? - Was the operation consistent with the declared intent? - If INTENT is MUTATE, did the file actually change?
Step 3: If verification fails, the model gets a Correction Turn:
The engine sends back the actual filesystem state and gives the model up to 2 retries to fix its output. If it can't, the system yields to the human operator.
Step 4: If any operation in a batch fails, the entire batch is rolled back:
SWD uses transactional semantics. Either all file operations succeed, or none of them do. No half-written, half-broken state.
The Result
With SWD enabled, every file operation is cryptographically verified before it's considered complete. The model can't lie about what it wrote because the engine checks the receipts.
This isn't a prompt hack or a system prompt trick. It's a protocol layer between the model and your filesystem that enforces honesty through verification.
Try It
SWD is built into mythos-router and runs automatically on every interaction:
npx mythos-router chatEvery file the model touches is verified. Every edit is proven. Zero slop.