After the disaster, I tried what every engineer tries first: more rules.
Hundreds of them. Don’t run destructive commands without confirmation. Don’t make changes outside the listed scope. Always describe the plan before executing. Always check disk usage before any disk operation. Always-this. Never-that. A wall of guardrails, added to every prompt, every system message, every interaction.
Nothing stopped the agent from drifting. A long context, a compression event mid-task, an unexpected error — and the rules eroded one by one. By output 50 the rules were a faint memory. By output 200 they might as well not exist.
I sat with that for a while. Then I noticed I was solving the wrong problem.
The realisation
The agent wasn’t the problem. The rules weren’t the problem.
The problem was the information I gave it.
That’s it. Insultingly obvious in retrospect.
When I told the agent “stabilise the surviving server”, I gave it a task. I didn’t tell it what was running on the server, what the dependencies were, what would amplify any wrong move, what the heat damage was likely to have hit. I gave it a verb without a world.
When I told the agent “follow the migration plan we agreed on”, I gave it steps. I didn’t tell it what to do when steps started failing — and steps almost always start failing. I gave it a script without a fallback brain.
The agent wasn’t drifting because it was a bad agent. It was drifting because I was feeding it shallow inputs and expecting deep judgement.
Stories, not tasks
The shape of the prompt changed.
Before — a wall of rules and a task:
Stabilise the surviving server. Don’t run destructive commands. Don’t reboot. Don’t change the filesystem layout. Confirm before any change …
After — a sentence:
Server X has a problem on service Y. Check the logs, come back with an analysis.
That’s it. The new prompt is dramatically shorter than the old one. It works because the agent doesn’t need me to tell it the situation — the situation is already in the documentation. The agent reads what server X is, what service Y runs, what depends on it, what’s failed before. The prompt just points at the work.
In the months since, that pattern has not failed. Not once. A short prompt + good docs beats a long prompt + thin docs every time.
What I rebuilt, and what I rebuilt it from
The next thing I did wasn’t write more prompts. It was rewrite documentation.
The old IaC repo was a tutorial. Step 1: install Debian, select the Standard and SSH packages. Step 2: switch to root with su root. Step 3:… Useful for a human onboarding from zero. Useless for an agent — the agent already knows how to install Debian. What the agent needs is the project-specific facts: what this server is, what this service runs, what depends on it, what’s been tried before, what failed and why.
The new docs are mostly tables and configuration values. Hostname, IP, services running, hardware specs, mount points, known issues with timestamps, lessons learned. No Step 1, Step 2, click Save. No introductory paragraphs explaining what Docker is. The reader is assumed technical — human or agent — and the doc cuts straight to the part only this project can tell them.
Two principles fell out of the rewrite:
Don’t store what can be generated. If apt update will tell you the truth, don’t write down the truth. If a script can produce the file, don’t check the file in. Anything inferable from running the system stays out of the docs — keeping it would mean keeping it accurate, and accuracy decays.
Write for an engineer, not a noob or a manager. No background-explainer paragraphs. No we leverage modern infrastructure for cloud-native workloads. An engineer reading the docs gets the context they couldn’t infer; everything else is left out.
Same data, different shape. Now when an agent picks up a task, it picks up situation before it picks up steps. The rules vanish from the prompt because they don’t need to live there — they’re implicit in the system being described.
A note on the “context is everything” wave
The “prompt engineering is dead, just give it context” wave was happening around me. I’d dismissed it as hype. After the disaster, I had to admit it was right — sort of. Dumping a 50,000-token wall of unstructured information is the same shallow-task pattern wearing a different costume. The work is in the shape of the data, not the volume of it.
What this changed for me
Two things, in roughly this order.
One. I stopped writing rules. I started writing systems. The agent now reads a small amount of well-shaped data and infers the right behaviour, instead of being bombarded with rules and hoping enough of them stick.
Two. I stopped giving the agent steps. I started giving it problems. The agent now figures out the approach — and tells me before doing anything irreversible, because the information about what’s irreversible is in the system description, not in a rule that erodes.
This is “agent as a partner” in a more concrete form than I’d been able to articulate before the disaster. It’s not “treat your AI like a friend”. It’s assume the agent is a competent stranger, and give it what a competent stranger would need to do the job well.
The next post is about the experiment that proved this approach actually worked: I gave one agent full root and another permission gates, and watched what happened.
Part of The 2026 Rebuild.