🤖 Autonomy: Agents Work 24/7
The most immediate advantage of loop engineering is autonomy: once configured, the system keeps working without needing a human in front of the terminal. The loop wakes the agent, the agent executes and validates, and the loop schedules the next iteration. The human sleeps; the agent works.
💬 What This Means in Practice
"We set up Claude to basically wake itself up every five minutes. And of course, you can adjust this. And it's going to look for input in an external system like GitHub, for example. And so as long as our terminal is up and running with Claude Code, it's able to autonomously handle this."
Imagine a real-world scenario: you have 20 open issues on GitHub. Instead of resolving them one by one while sitting at your desk, you configure the orchestrator with the spec, define the validation criteria, and go to sleep. When you wake up, the system has processed 15 of the 20 issues, created PRs, and is waiting for your review on the 5 that had validation problems.
⏰ Scenarios Where Autonomy Shines
- ✓Overnight maintenance: resolve low-priority issues overnight
- ✓Continuous monitoring: check repositories for new issues every X minutes
- ✓Backlog processing: tackle a backlog of tasks in a batch
- ✓Automated review: preliminary code review on PRs while the team sleeps
📈 Scaling: Parallelism with Worktrees
The second major advantage is horizontal scaling. Instead of processing tasks sequentially, the orchestrator can dispatch multiple workers to run in parallel, each in an isolated git worktree. Development throughput multiplies.
"We can use Archon to send off workflows to run in parallel, handling multiple GitHub issues at the exact same time. [...] We have our Cloud Code here kicking off four workflows to handle GitHub issues."
✓ With Parallelism
- ✓4 issues resolved at the same time
- ✓Each worker in its own isolated worktree
- ✓Neon database branches for data isolation
- ✓Merge controlled by the orchestrator
✗ No Parallelism
- ✗1 issue at a time, sequentially
- ✗Total time = sum of all tasks
- ✗Human blocked until completion
- ✗No use of idle resources
Cole demonstrates that in his Archon approach, the main orchestrator launches 4 fix workflows, validates that the PRs were created, and then launches 4 code review workflows. That’s 9+ agent sessions working in coordination, but each one is "lean" and focused on its task.
🧱 Composability: Modular System
The orchestrator-workers architecture is naturally modular. Each component has a clear responsibility and can be swapped independently. The orchestrator can use a different model from the workers. The workers can use different models from one another. The state store can be Postgres, SQLite, or any other database.
"Posso decidir qual modelo usar em cada nó deste fluxo de trabalho do Archon. [...] Podemos usar o Claude Code para implementar e o Codex para revisar. Para carregar o contexto e explorar no início, podemos usar um modelo menor, como o Kimi K 2.7."
🧩 Example Model Mix
Classify (triage)
Small, inexpensive model (Haiku, Kimi K 2.7). Decides whether the issue is a bug or a feature. Doesn’t need heavy reasoning.
Research (exploration)
Mid-tier model for exploring the codebase and understanding the context. Good reading ability, moderate cost.
Implement (code)
Powerful model (Claude Sonnet/Opus). This is where real reasoning matters: writing code, fixing bugs.
Review (validation)
Another model (Codex, or the same one used for implementation). Checks whether the code is correct, tests pass, and the PR is ready.
💡 Exploration and Proof of Concept
Cole Medin identifies a use case where loop engineering works particularly well: exploration and proofs of concept. When the goal isn't to deliver production code, but to validate a hypothesis, test an approach, or prototype quickly, loops are powerful tools.
"And I think it’s really good for building proofs of concept and exploring ideas. But I don’t want to do all my AI-assisted coding with it."
📝 Exploration in Practice
Cole demonstrated it in the dashboard he built: "I just have been going through a lot of really simple examples, but like non-trivial enough where it does have to go through quite a few rounds to build it. So like building a single page Kanban board as a static web app." The agent explored, iterated, and produced a working prototype in automated rounds.
For exploration, the high cost is acceptable because the goal is to learn, not deliver. If the PoC works, you refine it manually. If it doesn't, you discard it and try another approach. Loops speed up this trial-and-error cycle.
🏋 Incrementality: Small Cycles
A central principle of loop engineering is that large tasks should be divided into small cycles. Instead of asking the agent to build an entire app at once, the loop ensures it does one task per iteration, validates it, and only then moves on to the next.
"We never want to have a coding agent try to handle too much at once, or it will get completely overwhelmed."
🔄 How Incrementality Works
Round 1: Task 1
The agent picks up the first task from plan.md, executes it, validates it (do the tests pass?), and marks it as complete. The loop schedules the next wake-up.
Round 2: Task 2
The agent wakes up, reads the state (task 1 is done), picks up task 2, executes it, and validates it. The context is fresh because each round can be a new session.
Round N: Completion
When all tasks are marked done, the loop detects that the goal has been reached and stops. The orchestrator reports the final result to the human.
🎯 Reflection Point
Incrementality is the natural defense against two problems: context bloat (each round can have fresh context) and compounding hallucinations (validation between rounds catches errors early). It is the principle that makes loops work instead of being a blind gamble.
❓ Questions
The benefits are real, but they need to be assessed honestly. Every benefit has a cost or a condition that must be met.
Autonomy requires trust in the harness
Leaving agents running unsupervised only works if the harness is robust. Without observability, cost tracking, and validation gates, autonomy becomes negligence. Cole doesn't run blind loops: "we can always have it pause for us to validate something before it continues."
Scale multiplies cost, not just throughput
4 workers in parallel resolve 4 issues faster, but they also use 4x the tokens. If each issue costs $5 in tokens, 4 in parallel cost $20. Scale is a real advantage, but it's expensive. The ROI depends on the value of the tasks being automated.
Composability requires significant engineering
Building a system with a mix of models, a state store, worktrees, and validation gates is not trivial. Composability is an architectural advantage, not an advantage that materializes on its own. Someone needs to build and maintain the harness.
🤔 Reflection Point
Cole sums it up: "I like the concept of it, and I want to drive how autonomous my coding agents can be, but you got to have the right system. Otherwise, things are going to completely fall apart." The benefits are real, but conditional. The next module (2.2) will show what happens when those conditions aren't met.
📋 Module Summary
Next Module:
2.2 — Disadvantages and Risks