An excellent article, thank you! The current hype around loops is so out of touch to me. You can't just set a veil goal like "Optimize landing page for conversion" and expect the agent to perform magic. It still needs understanding, plans, goals, handoffs, and trust. For some use cases "optimizing" towards loops might not be feasible at all. And then, there's token cost, agent fleets and infinite loops are really great if you're OpenAI or Anthropic. They're maybe not so great if you burn millions of tokens on something where a quick steering, a little nudge in the right direction, could have saved hundreds or thousands of dollars. Especially if the task or goal is vague, the user expects some kind of magic, and the agents spin eternally, then you'll see horrendous token spend with little to no benefit.
Thanks Jens! I think you put your finger on exactly the failure mode I was trying to warn against. A goal like "optimize landing page for conversion" fails the test I care most about: which is it isn't measurable in a way a machine can check, so the agent kinda has no honest stopping condition and just burns tokens looking busy.
That's why I put budget in the contract right alongside the goal - a token ceiling, an attempt limit, a cap on parallelism or something like that. You're right that the incentives don't all point the same way here, which is more reason for teams to treat "quick steering nudge vs. let it spin" as a real cost decision. Most of the time the nudge wins.
We’ve been exploring this as a team. We have a few loops that we’ve already implemented completely autonomously. One is a product improvement RSI where the agent (as a PMT) does a review of a specific feature for improvements, misses, etc. another is actively seeking bugs, and then there’s the operations engineer fixing broken pipelines. All of these rely on logs, validation, success criteria. They require thought to implement but once they’re going I notice that the engineer needs to let go of the training wheels.
Great contribution, Sam. What stands out to me is that all three loops you describe kinda share the same backbone. The loop isn't what makes it work but the verification underneath it is. And your "let go of the training wheels" line is a nice way to name the human transition that has to happen once the evidence is trustworthy - the hard part is usually us, not the agent. Would love to hear how you're handling review queues and token spend once several of these are running at once. I think that's where the orchestration tax tends to show up.
You're hitting the critical point. What I tell my team: don't just move work bucket to bucket. Following value-pipeline methodology, that's not progress—it's toil. CRs pile up, nobody catches up, work goes stale.
Two things helping us with the review-queue and token-spend problem:
First, we feed overnight agents smaller, simpler items that can be confirmed in the morning, and we force the agent to validate its own work and attach evidence to the CR. That alone speeds up approvals a lot.
Second, some of us run Asana boards with staged columns: human triage (fed by an agent surfacing opportunities) → ready for agent (after human validation) → ready for test (QA agent re-verifies in pre-prod) → ready for final human check. As the evidence gets trustworthy, the human stages drop out one by one.
On cost: it's subjective, but token spend is still well below value created. Anecdotally we hit 4x on large projects before RSI loops—now we're gearing up for a more ambitious one and think we can double that.
The industry is currently suffering from a severe case of what I call software fleet cosplay. People are spinning up hundreds of parallel agent loops. They expect magical optimization of vague landing page goals, but they are actually just burning valuable margins. It's a fundamental misunderstanding. Autonomy isn't a ladder of qualitative trust. It's a phase-transition governed by thermodynamic constraints. When you let an agent modify its own environment, its behavior inevitably decays. This is a mathematical certainty. Standard alignment methods like RLHF break down instantly during self-modification. To survive this, we must shift the entire security paradigm. Stop trying to steer chaotic model outputs with soft prompt instructions. You need to compile continuous neural behaviors directly into static, hardware-attested memory pages inside local enclaves. If you don't do this, the local 12°C per millisecond thermal transients on sub-2nm nodes will collapse your hardware before you can execute a recovery route. Why is your system still treating a probabilistic LLM text log as a secure runtime instruction? Let's talk about what happens when your local memory bus fails tomorrow. 🛠️⚡️
Great article, thanks! Would be curious whether you have some concrete examples of how this can look into practice - e.g., some GitHub repos or code snippets that you find useful?
While the concepts make sense and are fascinating, I found myself struggling a bit to translate them into actual code, so seeing a working example would really help bridge the gap
I run the same model at multiple levels simultaneously. The real sort key is reversibility, not trust. Undoable stuff runs open-loop, anything public or irreversible gets a human gate regardless of track record. The mistake is promoting the whole system when only some actions earned it.
This is the autonomy ladder I would want clinical-agent teams to use too. The jump from supervised tool use to open-loop action should require a contract the workflow can inspect: measurable goal, source boundary, budget, stop condition, and human owner for exceptions.
Around an OR-adjacent agent, the unsafe version is not a bad summary. It is a loop that keeps reconciling or routing because no one defined what evidence is enough to stop.
Thank you. This is a thoughtful walkthrough of autonomy levels, and the framing around agency versus orchestration is genuinely certainly helpful. The only thing I’d add is that once systems can choose actions, coordinate tools, and operate across many agents, the challenge becomes governance rather than capability.
Autonomy isn’t just a technical gradient, it’s a question of authority, boundaries, and evidence. Clear contracts, measurable stopping conditions, and defensible verification make the higher rungs workable. The climb is real, but the structure around the climb matters just as much.
An excellent article, thank you! The current hype around loops is so out of touch to me. You can't just set a veil goal like "Optimize landing page for conversion" and expect the agent to perform magic. It still needs understanding, plans, goals, handoffs, and trust. For some use cases "optimizing" towards loops might not be feasible at all. And then, there's token cost, agent fleets and infinite loops are really great if you're OpenAI or Anthropic. They're maybe not so great if you burn millions of tokens on something where a quick steering, a little nudge in the right direction, could have saved hundreds or thousands of dollars. Especially if the task or goal is vague, the user expects some kind of magic, and the agents spin eternally, then you'll see horrendous token spend with little to no benefit.
Thanks Jens! I think you put your finger on exactly the failure mode I was trying to warn against. A goal like "optimize landing page for conversion" fails the test I care most about: which is it isn't measurable in a way a machine can check, so the agent kinda has no honest stopping condition and just burns tokens looking busy.
That's why I put budget in the contract right alongside the goal - a token ceiling, an attempt limit, a cap on parallelism or something like that. You're right that the incentives don't all point the same way here, which is more reason for teams to treat "quick steering nudge vs. let it spin" as a real cost decision. Most of the time the nudge wins.
We’ve been exploring this as a team. We have a few loops that we’ve already implemented completely autonomously. One is a product improvement RSI where the agent (as a PMT) does a review of a specific feature for improvements, misses, etc. another is actively seeking bugs, and then there’s the operations engineer fixing broken pipelines. All of these rely on logs, validation, success criteria. They require thought to implement but once they’re going I notice that the engineer needs to let go of the training wheels.
Great contribution, Sam. What stands out to me is that all three loops you describe kinda share the same backbone. The loop isn't what makes it work but the verification underneath it is. And your "let go of the training wheels" line is a nice way to name the human transition that has to happen once the evidence is trustworthy - the hard part is usually us, not the agent. Would love to hear how you're handling review queues and token spend once several of these are running at once. I think that's where the orchestration tax tends to show up.
You're hitting the critical point. What I tell my team: don't just move work bucket to bucket. Following value-pipeline methodology, that's not progress—it's toil. CRs pile up, nobody catches up, work goes stale.
Two things helping us with the review-queue and token-spend problem:
First, we feed overnight agents smaller, simpler items that can be confirmed in the morning, and we force the agent to validate its own work and attach evidence to the CR. That alone speeds up approvals a lot.
Second, some of us run Asana boards with staged columns: human triage (fed by an agent surfacing opportunities) → ready for agent (after human validation) → ready for test (QA agent re-verifies in pre-prod) → ready for final human check. As the evidence gets trustworthy, the human stages drop out one by one.
On cost: it's subjective, but token spend is still well below value created. Anecdotally we hit 4x on large projects before RSI loops—now we're gearing up for a more ambitious one and think we can double that.
The industry is currently suffering from a severe case of what I call software fleet cosplay. People are spinning up hundreds of parallel agent loops. They expect magical optimization of vague landing page goals, but they are actually just burning valuable margins. It's a fundamental misunderstanding. Autonomy isn't a ladder of qualitative trust. It's a phase-transition governed by thermodynamic constraints. When you let an agent modify its own environment, its behavior inevitably decays. This is a mathematical certainty. Standard alignment methods like RLHF break down instantly during self-modification. To survive this, we must shift the entire security paradigm. Stop trying to steer chaotic model outputs with soft prompt instructions. You need to compile continuous neural behaviors directly into static, hardware-attested memory pages inside local enclaves. If you don't do this, the local 12°C per millisecond thermal transients on sub-2nm nodes will collapse your hardware before you can execute a recovery route. Why is your system still treating a probabilistic LLM text log as a secure runtime instruction? Let's talk about what happens when your local memory bus fails tomorrow. 🛠️⚡️
Great article, thanks! Would be curious whether you have some concrete examples of how this can look into practice - e.g., some GitHub repos or code snippets that you find useful?
While the concepts make sense and are fascinating, I found myself struggling a bit to translate them into actual code, so seeing a working example would really help bridge the gap
I run the same model at multiple levels simultaneously. The real sort key is reversibility, not trust. Undoable stuff runs open-loop, anything public or irreversible gets a human gate regardless of track record. The mistake is promoting the whole system when only some actions earned it.
This is the autonomy ladder I would want clinical-agent teams to use too. The jump from supervised tool use to open-loop action should require a contract the workflow can inspect: measurable goal, source boundary, budget, stop condition, and human owner for exceptions.
Around an OR-adjacent agent, the unsafe version is not a bad summary. It is a loop that keeps reconciling or routing because no one defined what evidence is enough to stop.
Thank you. This is a thoughtful walkthrough of autonomy levels, and the framing around agency versus orchestration is genuinely certainly helpful. The only thing I’d add is that once systems can choose actions, coordinate tools, and operate across many agents, the challenge becomes governance rather than capability.
Autonomy isn’t just a technical gradient, it’s a question of authority, boundaries, and evidence. Clear contracts, measurable stopping conditions, and defensible verification make the higher rungs workable. The climb is real, but the structure around the climb matters just as much.