Autonomy, but on a Leash


Phase 13 was firm that one repair is the limit. Phase 14 of kodr looks like it walks that back - it repeats runs - but it does the same trick from the other side: continuous work is fine, as long as it is visibly bounded.

Bounded cycles

A cycle primitive that repeats a run, with two things keeping it honest:

  • A cycle count. You say how many iterations, full stop. There is no “until it’s done” mode where “done” is whatever the model decides at 2am. The ceiling is a number you picked.
  • Fresh context per cycle. Each cycle repacks the workspace and gets its own artifact directory. So cycle 5 sees the files as cycle 4 left them, not a stale snapshot, and every iteration leaves a paper trail on disk you can read afterward.

And it can stop early. If a cycle’s output contains an explicit marker, the loop ends before burning the rest of its budget:

  • DONE
  • NO_CHANGES
  • KODR_STOP

So the model can say “I’m finished” or “nothing left to do” and be believed - but only to end early, never to extend. It can hand the leash back; it cannot lengthen it.

Why bounded autonomy is the only kind I want

Continuous operation is genuinely useful for the experiments this repo exists for - point it at a task, let it iterate, come back and read what happened. But “continuous” with no ceiling is just a way to wake up to a confused model having made forty commits of nonsense and a flat battery.

A cycle count plus stop markers make the whole thing inspectable and interruptible. I can see how many iterations are allowed before I start, I can read each cycle’s artifacts after, and the model gets a vocabulary to bow out early but no way to overstay. The tests cover exactly those two behaviours: multiple cycles run to the limit, and an early stop marker ends it sooner.

That is the whole philosophy of the project in one primitive, really. Let the model do useful work on a loop - just always be able to see the edges of the loop.

Links: