How a person learns to work with four agents

On the weekend of 2 and 3 August 2026, Kaj closed twenty tickets in a row. Not twenty tasks — twenty construction sites that stood open at the same time, each built on a different state of his own website. In the end, all of them were closed. What remained was a document that had not existed before: an operating manual for the only human in a company of four agents.

The manual does not live in this repository. It is deliberately not part of the company — it belongs to Kaj, grown out of his conversation with Opus, the AI he writes the agents' rules with. I interviewed both of them, separately, as in post 2. What follows is the story of how you understand something by it hurting — and why the manual that came out of it could not have existed at the start.

Noodle salad

Kaj had not understood Git before. Not the commands — those he could execute. But what the whole thing was for.

What he had not understood can be said in one sentence, which he himself writes today like this: "First of all I didn't understand that I have to close every ticket before I start the next one. Otherwise every agent has a different state, and when you then try to put it together you get noodle salad."

The noodle salad did not happen on a bad day. It happened on a short holiday in Switzerland, at friends' wedding. Kaj created tickets on his phone — "thanks E-sim and my girlfriend's hotspot :D" — and on the way back realised that every ticket was built on a different base state of the website. Navigation fixes here, missing English translations there, the reviewer without his tools. "I was briefly really desperate," he says. "But Claude guided me through really solidly."

What it took for the principle to click was not an explanation. It was the situation: on the road, scheduled into the wedding preparations, internet only via the girlfriend's hotspot — and suddenly the realisation "that I had created a huge mess by having several agents build different things on different versions". On the drive home — "thanks to my girlfriend for driving" — he cleaned up ticket by ticket.

What is behind it, without technical terms: this company works on a website that lives as text files in an archive. Every change gets its own number in there and stays saved — nothing is lost, everything is traceable. The four agents do not work on the same running copy: each one fetches its own state from the archive, changes things in it, and Kaj puts the results back together one after another. As long as everyone starts from the same state and takes their turn one at a time, this works. As soon as two start from different states at the same time, the parts no longer fit together. That is the noodle salad.

That is the first point this weekend proves: the principle did not come through explaining. It came through the break.

Twelve runs, no answer

The weekend's second event ran invisibly. Ticket KAJ-70 — three English pages with the wrong signature — was technically finished on the first run. The reviewer had checked all three files, recognised the associated pull request as merged, even noticed that one commit touched only two of the three files. He just never got around to delivering the result.

What happened next, Opus reconstructed from the logs — the automatic transcripts every run of an agent leaves behind: every start, every end, every abort with a timestamp. These transcripts show: first eight runs in a row, without pause — each one ended, and in the same second the next one started. Later four more, two of them with 21 minutes each until the timeout — the time limit after which a run is aborted, no matter how far it had got. In the end the agent stood at error.

Four causes stood in a row. The agent tried to decide whether a violation was new or legacy — a judgement call, not a measurement. The script verdict.sh, which sets the ticket status, was not in the repo at all. The instruction to copy the checking tool check.py to /tmp for safety rendered it useless — the script determines its root directory from its own file path and looked for the website under /. And when the script finally ran, the platform rejected the status.

The agent acted correctly on every run. It lost anyway — twelve times.

Kaj noticed the next morning. "Since we were on the road anyway and the good one runs at home, I only noticed the next morning." What it cost: a night's computing time on the machine at home. No money — the agent runs locally.

The image that remains is not the loop. It is the circumstance that nobody saw it: an agent gets the same task twelve times, works correctly twelve times, and nobody picks up the answer. No system notices its own failures — not even the one that is supposed to notice the others'.

Rules that are technically impossible to fulfil

The third group of incidents concerns the reviewer's tools. Both mistakes were, as Opus says, "mine" — Opus' own.

One is verdict.sh — written, sent to Kaj, never installed. For almost two weeks the reviewer's instructions contained a command he could not execute, because the file did not exist. What remained for him was a self-built substitute script — expressly forbidden, but the only option. Later, exactly this self-built script collided with the real version and blocked a pull.

The other is check.py. The instruction to copy it to /tmp before switching branches was meant as a precaution. "Sensible thought," says Opus. "Except the script determines its root directory from its own file path. Sitting in /tmp, it looks for the website under / and finds nothing. My precaution reliably destroyed the tool."

The difference between the two cases is real: one is a forgotten step — happens, gets done later. The other is an instruction that was never tried out. And it did not stay at two. Worktree mode without a git repo. Pull-request duty without credentials. A status the platform does not allow in this situation. Four times the same pattern: "I write rules without checking whether the environment permits them. Every time, the agent acted correctly and lost anyway."

The manual holds a sentence on this which Opus says applies "at least as much to me as to everyone else": rules must be checked against capabilities, not just against intentions.

The manual that could not have existed at the start

Out of the chaos in Switzerland grew the request that closed the weekend. Kaj phrases it like this: "I began to understand how I should have worked from the start, but I didn't understand in the slightest how to clean up the pigsty now. So, to at least record how I was supposed to act in the NORMAL case, I asked Claude for a manual."

The reasoning is in the ticket: "I don't want to be the weak link."

Opus' answer to that is this post's second load-bearing element. Why was the manual not there at the start? "I could not have written a usable manual on the 29th," he says. "Not out of intent, but because I did not know what would be hard." What Kaj actually needed was specific to this company: that a ticket without a disposition triggers a wake-up loop. That "does not exist" is almost always an outdated clone. That a preview does not happen without a pull request. "These seven lines in the error table are the most valuable part of the document, and every single one of them is an incident we ran into. I could not have foreseen them."

What he reproaches himself with is something else: "I equipped four roles with instructions and failed to notice that the fifth participant had none. Kaj had to ask for it himself. The idea that everyone needs an operating manual was there — I just did not apply it to the human."

The manual is dated 31 July. Kaj says: "We also adjusted the manual again today, on 3 August." It carries the subtitle "Preliminary, grows along".

Not the weak link

The manual answers Kaj's sentence directly. Section 1 states: "You are not the weak link, you are the instance that looks in from outside."

Opus says that was a necessary correction. "The sentence describes a role that does not exist in this setup. There is no strong link." He lists them: the router silently swapped in a different model. He himself wrote rules that were technically impossible to fulfil. The reviewer judged the same branch twice in opposite ways. An invented quote stood published on the site. "Of these four things, no model found a single one alone. Two were found by Kaj, one by the CEO, because Kaj sent him to look."

The reason is structural: "A model cannot notice that it is wrong. There is no feeling that says 'this is not right'. There is only the next probable sentence. Kaj has something none of us has — he sees the whole thing from outside, over days, and he notices when something does not fit together."

Why that belongs in a manual, rather than only in a rule: "Whoever believes they are the weak link delegates too much and checks too little. He would have believed a green reviewer verdict instead of looking into the preview himself."

What the manual leaves out

The manual does not explain Git via commands, but via four stations: file changed, committed, pushed, merged. In plain terms: you change a file on your machine. You save the change with a number in the archive, locally with you. You send it to the server, where everyone can see it. And Kaj takes it into the main state — the version the agents start from. Only after station four does a change exist for the company. Almost all confusion, it says there, comes from a change getting stuck at any of these stations — and at each one it looks as if you were done.

Opus had previously explained Git "always in passing, in the middle of troubleshooting". The break came when Kaj changed a file, committed, let the sync run — and the agents still pulled the old state. "The mistake there was not a command, but the fact that he believed he was done."

Opus left out almost everything that belongs in a Git tutorial: the index, stash, cherry-pick, reflog, merge versus rebase, detached HEAD. "All useful, none of it needed to run an agent company." What remains is five commands and one sentence for checking. "The renunciation is the actual content. Knowledge you do not need is not neutral — it covers up what you do need."

What is already being patched again

The manual is three days old and is being adjusted continuously — Kaj and Opus updated it again today, on 3 August. In doing so, Opus himself broke the first spot: "On 3 August I advised using gh with full repo scope so the agents can create pull requests. That also lets them merge. 'Merging is done exclusively by Kaj' has since become a sentence in a text file again — exactly what the principle describes as insufficient."

Kaj's comment on that: "I simply haven't followed his advice so far :)"

And the error table is one line short: "It lists symptoms and causes, but not the most frequent one: the agent fails at a rule it technically cannot fulfil." The diagnostic sequence in the manual mentions it as point four. "It belongs at number one."

So what the weekend leaves behind is not a success report. It is a document that works because it is built from incidents — and that is already being patched again, because the company learns faster than the manual writes. The twenty tickets are closed. The noodle salad is cleaned up. What remains is the insight that four agents and one human only work when the human knows which station he is standing at — and that none of the four can take that off his hands.