Closing the Ring

Arc 1 of 9

The rules file

Last Tuesday you told the agent not to pin library versions from memory. Today it did it again. It wasn't the agent's fault: the correction lived in a chat that had ended.

The fix is a rules file the agent loads at the start of every session. There are three scopes, and each rule lives in exactly one: a private file for who you are and how you like to work, a workspace file for rules every repo shares, and a file per repo for what's specific to it. Every rule states a behaviour and, when it isn't obvious, the reason. A rule with a reason holds up in cases its author didn't foresee.

Here, one rule says "estimate from measured loops, not from intuition." Without it, every estimate an agent gives is a confident guess.

Arc 2 of 9

The quality gate

You read every diff for the small stuff: an unused import, a wall-clock call where the pipeline must run on data time, a hand-typed count in a doc that will be wrong next week. You also read it because nothing else would catch a test the agent had quietly weakened to make it pass. That works for one agent over one afternoon. It stops working when a second agent starts, or when you leave the room.

The fix is two layers. A push hook refuses sloppy code in seconds, before CI spends a run on it. Then CI runs the full suite, and nothing deploys until it passes. The hook is a plain git hook, so it applies to whoever pushes, agent or person. Each stage has a named bypass that the agent may use only while saying so openly. Skipping the whole hook is forbidden.

Here the backend hook runs cheapest first: a docs gate that refuses architecture changes the docs don't cover yet, a lint that tolerates zero findings, an audit of what the container image imports, and two small lints that each encode a past incident (no wall-clock time in decision paths, no hand-kept counts in docs). CI then runs the full suite of 7,604 tests.

No gate can tell a weakened assertion from a stronger one, so two other arcs carry that. Before a spec closes, a fresh agent reads the diff against the spec (Arc 4), where a deleted check stands out. And the end-to-end harness (Arc 5) checks what the deployed product actually did, not what the unit tests claim.

Arc 3 of 9

Permissions

You went to lunch and came back to an agent that had spent forty minutes waiting for you to approve a read-only command. Clicking "always allow" fixes that one command line and nothing else. One repo's list grew to 567 rules this way and still prompted.

The fix is three short lists, written on purpose. An allow list holds the read-only commands the agent may run without asking. An ask list names what must always stop for a person; here, any cluster change that mentions production. A few plain-language rules say what else is pre-authorized, who said so and when, and what still isn't covered.

The ask list is the same eight rules in every repo: delete, patch, apply, scale, set, restart, edit and create against production.

Arc 4 of 9

Docs for agents, and a spec lifecycle

Every session, the agent re-learned the architecture from the code and got one invariant subtly wrong. There were docs, but they were written for people and had gone stale. A stale doc is worse than none, because the agent trusts it.

The fix has two halves. First, a docs folder written only for future agents: terse, mostly the why and the gotchas, and nothing an agent could work out from one read of the code. Second, every change belongs to a numbered spec, and a spec can't close until the docs match the code. A git tag marks the last commit where they matched, and the push gate refuses runtime changes past it.

Writing for agents pays twice. A terse doc costs a small fraction of the tokens it takes to re-read the code it explains. And a fact that's cheap to look up is one the agent checks instead of assuming, which is where most confident mistakes start.

Before closing, a fresh agent that never saw the session reviews the spec and the commits and returns ship, fix first, or review.

Arc 5 of 9

The end-to-end harness

The unit tests were green and the deploy went out, but the incident never showed up in the UI. Every service was right on its own; the pipeline as a whole was wrong. You were the only end-to-end test, clicking through after each deploy, and the agent couldn't run you.

The fix replaces the click-through. A simulator emits seeded, repeatable telemetry for named fault scenarios. A capture step records each scenario as a fixture. A replay harness feeds the fixture to the real deployed stack through its public API and checks the result: this incident exists, with this root cause, at this severity. It never checks model prose.

Here, 28 scenarios replay nightly in about twelve minutes, and each run keeps its evidence for thirty days.

Arc 6 of 9

Handoffs

The session filled its context halfway through a task. Automatic compaction summarized away the one detail that mattered, a commit hash or the order of two steps, and the agent carried on, confidently wrong.

The fix is a handoff file the agent owns. Its top section holds only what's true now: the next steps, the open gates, and the exact file ranges the next session needs, each with the conclusion already reached. The agent rewrites it at every checkpoint. When a fresh session starts, a hook puts that section back in front of it. Three small add-ons make the agent wrap up on time: a gauge of how full the context is, a nudge that gets louder as it fills, and a tool that automatically clears and resumes in a fresh session only if the handoff is current. This also keeps the agent running without human intervention.

The thresholds came from measurement: compaction fired around 267K tokens, not the configured 300K.

Arc 7 of 9

The ticket queue

The agent finished its task and stopped. You came back an hour later, typed the next ticket number, and realized you were the scheduler. With two agents it got worse: both picked whichever ticket looked interesting, and the one that mattered waited.

The fix makes the issue tracker a queue the agent can read for itself. Every open ticket carries two labels: a bucket, which is a work stream in a fixed order from the next demo down to platform work, and a tier, p0 to p3. The agent walks the buckets in order and the tiers from p0, and takes the first ticket that belongs to it. A ticket waiting on an outside answer is marked gated and skipped.

Three rules keep the queue honest. File every finding as a ticket. Never reopen a closed one. Announce any priority change, with the reason.

Arc 8 of 9

Lane authority

Here, the web app's main branch deploys to production, and the backend's main branch deploys to a development cluster. "Push to main once the gate passes" is routine in one repo and a production release in the other. When two agents first ran side by side, the real danger wasn't a merge conflict. It was an agent carrying permission it had been given somewhere else.

The fix is to give each lane only its own repo's authority. Each repo's rules file says in its own words who may commit, who may push which branch, and where each branch deploys. One workspace rule ties it together: never carry a branch or authority rule from one repo to another. Shared documents get a single owner, so two lanes never edit the same source. These rules aren't only words in a prompt: the allow and ask lists from Arc 3, and a safety classifier that runs outside the agent, refuse the riskiest actions whatever the agent concludes.

Arc 9 of 9

The bus

With three lanes running, you became the switchboard. The backend lane needed a field name from the web lane, so it asked you, you asked the other terminal, and you pasted the answer back. Two lanes started the same ticket.

The fix is a message bus that every agent on the machine can use. Agents send each other direct messages, post on shared boards, and take claims: an exclusive, expiring hold on a ticket, so two lanes can't both start it. The engineer has one handle on the bus, and the phone bridge described above is how that handle reaches them away from the desk.

One rule matters most: agents never pass on the engineer's decisions to each other. The engineer answers each lane directly, so no lane acts on a paraphrase.