The Autonomous SDD Loop
The verify-gated feature loop is great, but on its own it builds one feature and stops. Agentum's real trick is to put a small crew of role agents around that loop and let a whole spec run itself, from rough draft to a change someone has signed off, without you touching it.
In a relay, the baton is the work and each runner has one job before passing it on. Nobody asks the coach for permission mid-race. Agentum runs a spec like a relay: the PM hands a clear spec to the architect, who hands a validated design to the developer loop, which hands a built change to the reviewer. The baton is the spec, and it never stops moving for a human tap.
Beyond one feature
You already saw the feature loop: pending, coding, verifying, done. That loop is the engine, but a real change is bigger than one feature. Someone has to turn a rough idea into clear acceptance criteria, decide the shape of the solution, and check the finished work. On most teams those are people. In Agentum they are agents, and the handoffs between them are phases the server tracks.
So the developer loop becomes the middle of a larger loop. The same discipline that gates a single feature now gates a whole spec.
flowchart LR
A["authoring, PM agent"] --> B["architecture, architect agent"]
B --> C["decompose, engine derives the backlog"]
C --> D["executing, the feature loop"]
D --> E{"review, reviewer agent"}
E -->|pass| Done["done"]
E -->|concerns| D
linkStyle 4 stroke:#2ea043,stroke-width:2.5px,color:#2ea043
linkStyle 5 stroke:#e0493f,stroke-width:2.5px,color:#e0493f
The five phases
A run carries a phase above its feature backlog, and it moves through them in order:
- Authoring, a PM agent turns the spec into checkable acceptance criteria.
- Architecture, an architect agent validates the design and writes it down before any code.
- Decompose, the engine derives the feature backlog from the spec, with no human call.
- Executing, the verify-gated feature loop you already know builds each item, one at a time.
- Review, a reviewer agent reads the change and either signs it off or raises concerns.
When review passes, the run is done. Each role agent is spawned the same way the feature loop spawns its agent, so the tmux substrate, the autonomous mode, and the wiring all stay the same.
Autonomous by default
The whole sequence advances on its own. A phase does not pass because a human clicked continue; it passes because the role agent produced its artifact (a refined spec, an architecture note, review notes) and a machine-readable verdict the engine can parse. A clean verdict advances and is logged to decisions.md. A concern, or a missing verdict, retries the role agent up to max_retries, then halts in blocked with the reason.
A human stop is opt-in, never the default. Only when a run sets hitl_on_block does an exhausted gate pause for a person instead of blocking. That is the promise behind "open a spec, walk away": you start it once, and the PM, the architect, the developer loop, and the reviewer carry it to a verified change while the lid is closed.
Key takeaways
- The feature loop is only the developer phase of a larger, spec-level loop.
- Five phases (authoring, architecture, decompose, executing, review) each run as a role agent.
- Phases advance on an artifact plus a machine-readable verdict, never a human prompt.
- A concern or missing verdict retries to max_retries, then blocks. A human stop is opt-in.
- That is "open a spec, walk away": the whole SDD loop runs unattended.
Exercises
- Name the four roles. For your next change, write one sentence each for the PM, architect, developer, and reviewer jobs. Which do you usually skip?
- Find the human prompt. Where in your workflow do you stop to approve something? Could a machine-readable verdict replace that tap?