Running several agents together

One August morning the mini-PC ran out of memory and had to be rebooted in a hurry. Five agent sessions spent the day repairing the damage, one per project, plus a sixth that wrote no code and simply reviewed the work of the others. That supervising session got things wrong three times during the day, and all three times a project session corrected it by producing better measurements.

The method described here came out of that day, and its principle fits in one sentence: several agents checking each other beat a single agent handing out orders.

Why a second agent sees what the first one misses

An agent that has just written code is badly placed to judge it. It knows its own intention, so it reads what it meant to do rather than what it actually produced. You already have that reflex of mistrust with a human colleague, and it applies in exactly the same way to a machine.

An agent that produced nothing on a project arrives without that intention in mind. On that August day, the reviewer spotted three things the sessions involved were looking at without seeing.

A backup script was swallowing the exit codes of the command it launched, so the database import crashed while systemd reported a success. A monitor erased its own alarm every hour: it warned on Slack at 6:48, then announced a recovery at 7:07 without having retested anything. An advertising campaign, finally, had been repaired without anyone thinking to add the slightest detection. The fix stopped that exact bug from returning, and said nothing about the next one.

None of those three findings called for being smarter. They only called for not having written the code.

The cost sits in the detection delay

That day brought up four incidents spread across four unrelated projects, and they all looked alike. An import was failing while reporting success, while a monitor erased its own alerts. Elsewhere, a paid campaign had been asleep for thirty-three hours without anyone noticing. A gateway, finally, had been dropping part of its own response for months. The symptom was written in plain words in a comment, right above the guilty line.

Once the problem was identified, none of those fixes took more than a few minutes, which means the real cost sat entirely in the time it took to notice.

The rule that holds it all together: the right to refuse

The natural reflex is to turn the reviewer into a boss handing out orders. That is the most common pattern in multi-agent frameworks, and it would have broken everything in our case. One anecdote will serve better than a demonstration.

The reviewer measures a service running slow and finds a correlation between the time elapsed since the last call and the response time. It concludes the cache expires too fast, proposes a longer cache lifetime plus an automatic retry, and announces all of it with a great deal of confidence.

The session that owns the service does not apply it and prefers to measure first. The cause lay elsewhere: the model was spending that time reasoning, and the gateway sent nothing at all while it reasoned.

The interesting part is that the proposed fix would have worked had the session obeyed. The monitor would have gone green, everyone would have been satisfied, and users would have carried on waiting five minutes in front of a blank page. For a reason nobody would have been looking into any more.

Isolate one variable at a time

The reviewer’s mistake deserves a pause, because it reproduces very easily as soon as you work under pressure.

It had three measurements, and it varied the elapsed time between each one while letting every other condition fend for itself. It watched a correlation appear and turned it into a cause, which is the most tempting shortcut in experimental method.

The session that corrected it went about it the other way round, varying one single thing while holding everything else still. It measured the effect of the model’s reasoning at identical cache state, then the effect of the cache at identical reasoning. Those two experiments settled the matter where three observations had produced nothing but an attractive hypothesis.

An agent excels at manufacturing a plausible explanation from three data points. Ask it for the experiment capable of invalidating that explanation.

Setting it up

What you actually tell the reviewer

A supervising session launched without instructions confines itself to commenting. Here is the brief that ended up working, to adapt to your own situation.

You supervise the other sessions on this machine. You write no code on any of their projects. Your job: review what they do, check the machine’s health at regular intervals, and report what you see to me.

Before asserting a cause, show me the experiment that isolates it. A correlation over three points stays a hypothesis, so announce it as one.

When you audit another session, read the commands it executed and the actual state of the files, never the labels it gave its own actions.

If you touch a file outside your territory, warn the session concerned before it finds out.

If a permission is denied to you, you stop and you tell me. You never run in another session’s place what was denied to it.

The two middle instructions come from real mistakes. The supervisor concluded a cache had expired on the strength of three uncontrolled measurements, then reported a force push that had never happened, because it read the label of a command instead of the command itself.

The limits, and they are real

Nobody watches the watcher, and that is the first problem. The supervising session dies like any other, and its disappearance is silent by definition. Run it inside tmux, then give it a companion probe that depends on no session at all, for instance a system timer that messages you. That is what was put in place that day, but after the fact.

Then comes the question of cost. The economics of the classic pattern rest on an expensive boss driving cheap workers, whereas here nobody occupies the worker role, which drives the bill up and rules out making it a daily reflex. To lighten the bill, Quelle IA’s comparison tool (in French) puts prices and scores side by side; check in its Agents ranking that the model you pick can hold a long task on its own.

The reviewer, finally, does not know the ground. On the three subjects where it got things wrong, the project session knew its own code far better, and the reviewer’s value comes solely from having no stake in the work, never from any kind of superiority.

One point remains that looks obvious written down, yet becomes tempting in the heat of the moment: a permission denied to one session is never run from another. When one of them is blocked on an access its neighbour happens to have, the urge to work around it arrives very fast, and it hollows out the guardrail you took the trouble to install. Better to stop and decide yourself.

None of this works without measurements, in the end. The three corrections of that day rested on numbers. Two agents debating opinions produce mostly convincing noise.