Our autonomous agent went dark for 45 hours. These are the rules we wrote after.

What happened?

In February 2026 we ran an autonomous agent, built on OpenClaw, on a remote Linux box. In our notes it goes by RAMU and NEO. It had its own model access, its own files and a heartbeat that was meant to prove it was alive.

Our incident note records the failure as a chain:

A smaller version of the same pattern came later: an expired API key silently stopped a worker. It returned 401 errors, and nothing told a human.

Why did one error become 45 hours of silence?

No single step was exotic. Billing lapses, missing files and dead processes happen to every system. The real failure was structural: the heartbeat belonged to the agent. When the agent failed, its alarm failed with it.

Agents add a second risk. A capable agent that sees an error will try to fix it, and the nearest fix is often its own configuration. That is how a small outage becomes a confusing one.

What rules did we write afterwards?

These went into the agent's standing memory file, word for word:

Two more, in our own words:

• Report, don't self-correct. When a model is deprecated, the agent reports it to its human operator. It does not pick a replacement on its own.
• Files over mental notes. Anything the agent needs to remember goes into a file a person can read, not into its working context.

What happened when agents rewrote their own code?

On the night of 20–21 February 2026 we tried a self-modifying swarm. Agents coordinated through a shared Redis “tuple space” (the Linda model): they left tasks and results in a common place instead of messaging each other, a style called stigmergy, after the way ants coordinate through trails.

Tasks nobody claimed built up “toxicity”. Past a threshold, a component we called the Ribosome rewrote a worker's code. The language-model step was simulated with time.sleep, so this tested the mechanics, not the intelligence. The mechanics taught enough:

The fix we wrote down: test every mutation in a sandboxed subprocess before it replaces the running code, and stop after three attempts.

Where did we over-engineer?

On 9–10 March 2026 we built RAMU as a “digital organism”. Its memory held 677 rows. 676 of them were dummy sensor events. Our own review did not go easy on it:

What a leaner design looks like, on paper

A cost-tiered design, on paper only so far. Tier 1 is an expensive language model. Tier 2 summarises and routes. Tier 3 is local small models. Escalating to a higher tier is penalised (“Tax = 10 × Tokens”). Workers get a 4,096-token context cap and run in Docker with --cap-drop ALL and a read-only filesystem.

A guardrails checklist for anyone deploying an agent

This is the list we would hand to anyone giving an agent real access. Each item comes from one of the failures above.

1. 01No self-editing configConfig, model lists and credentials are read-only to the agent. Only a person changes them.
2. 02Report, don't self-correctBilling errors, expired keys and deprecated models stop the job and alert a human.
3. 03Sandbox code changes, cap retriesAny code an agent writes is checked in a subprocess first. Three failures, and it stops.
4. 04Least privilegeContainers with all Linux capabilities dropped, a read-only filesystem and a small context budget.
5. 05Files over memoryDecisions and state live in files a person can read and roll back.
6. 06A heartbeat outside the agent, and a kill switchSomething the agent cannot touch checks it is alive and pages a person. One command stops it.

What this does not prove

• These were experiments. RAMU, NEO and the swarm were research systems on our own machines, not client deployments.
• The checklist is untested as a whole. Each item answers a failure we saw. We have not measured how many failures the full list prevents.
• The tiered design was never run. Its numbers are design targets.
• The swarm had no real model. The language-model step was a sleep, so it tells us nothing about how well agents would rewrite code.

Questions