Keep Going: Autonomy Inside Rules for a Swarm of Agents

The agent that asks at every step

Run one AI coding agent and a question at every step feels like diligence. “Should I push?” “Want me to open the merge request?” “The pipeline’s still running, shall I wait?” Each one is cheap to answer.

Run a swarm and the same habit turns into the failure I described in an earlier post: every agent idles until I type, and I become the message bus again. Twenty lanes asking three small questions each is sixty interruptions before lunch, and none of them needs my judgment. They only need my permission, which I’d have given every time.

So the instruction I now give every agent is two words: keep going.

Keep going means finished, not “done”

“Done” is the cheapest word an agent has. It’s committed locally, the tests it chose to run passed, and it would like to know what to do next. That isn’t a result. It’s a hand-off with the hard part still attached.

Finished, in my lanes, is a short list that anyone can check from the forge:

the branch is pushed,
the merge request is open against the right base,
the pipeline is green, and if it isn’t, the agent has read the failure and fixed it.

That last item is where the work is. A red pipeline isn’t a reason to stop and report; it’s the next task. An agent that stops at “pushed, pipeline failed, what should I do?” has handed me the one thing it was in a position to do itself.

Autonomy comes from rules, not trust

I don’t let agents keep going because I trust them. I let them because the rules say what they may do without asking, and the rules are enforced somewhere the agent can’t argue with.

Each repo carries standing rules in the open, in the file the agent reads before it starts: who may push, who may merge, who may tag a release, who may deploy, and that the agent posts a plan before it changes anything. In uBixShepherd, the lane’s scope is a lease on a set of paths, and a pre-push hook refuses a commit that strays outside it.

Inside those rules the agent acts. It doesn’t ask whether it may push its own lane; the rule says it may. At the boundary it asks, and that’s the part people get backwards. Asking at the boundary isn’t a malfunction; it’s the system working.

I watched this happen. An agent finished a change and found it needed to touch a file just outside its lease. It could have rewritten the lease, committed anyway or tucked the edit into a neighbouring lane. The hook would have refused the push regardless, and the agent’s rules told it what to do: stop, say which path it needed and why, and ask. One short question, with the answer attached to the lane. That’s the cost of a boundary worth having.

Standards are what make that safe

Autonomy without gates is just speed. What makes “keep going” survivable is that the same checks apply to an agent as to me, and the agent can’t satisfy the ones that need a person.

One command for the local gate. make check runs the formatter, the linter, the tests and the type checks. If the agent runs it before pushing, most failures never reach CI.
The same checks in CI. The type checker and test run in the pipeline too, so a green local run isn’t taken on faith.
Approval is a failing check. As I wrote in the soft-approve lesson, a job fails until a person signs off. An agent’s change can go green on everything else and still sit there, and the agent’s report says so: it can’t approve its own change.

The point of the gates is that I don’t have to watch. An agent can’t talk its way past a red check, whatever its confidence. So I read the result, not the process.

A question answered once becomes a rule

The part that took me longest to notice: every question an agent asks is a failure of some rule that should have existed. If the answer is “yes, obviously,” the rule was missing. And if I answer the same question twice, I’ve failed too.

So answers don’t stay in a chat window. An answer becomes one of two things:

A recorded decision, with the question, the options offered and my own words, so the next agent can find it and not ask.
A standing rule, promoted into the repo’s rules once it has come up more than once. “Who may tag a release?” was answered once. Now it’s a line each agent reads.

The same discipline applies to what the agents record. A lane’s record said its merge request had been closed without merging. The agent checked that against the forge’s own merge state and found the change had landed. The agent didn’t ask me which was true, and it didn’t quietly rewrite the record either. It reported that the record was wrong and what the forge showed instead. The record itself stayed wrong; the agent had no business editing it, only evidence to hand over. A claim that a check can settle is not a question for a person; it’s a finding.

A flow along the top: the agent posts a plan, works inside its lane, runs make check, pushes and opens the merge request, and the pipeline runs to green and finished. A red pipeline loops back to work. Below, a step outside the rules makes the agent stop and ask the person, and the answer is recorded as a decision or standing rule that the next agent reads.

The principle

Every agent question should come from a boundary, and every answer should make the list of questions shorter.

Keep going until the work is finished and verified. Stop only where a rule says the call is the person’s, and when it is, write the answer down so no one asks again.