Most writing about AI-Driven Development describes a loop you run around an agent: you Ground it, Specify the work, freeze a Contract, go red, let it Build, Verify the evidence, Observe production, and fold the lessons back in. The loop is a process — discipline that lives in artifacts and gates, outside the model.
Nous Research’s Hermes Agent raises a sharper question. Hermes is an open-source autonomous agent with a built-in learning loop — a closed cycle of memory and skill curation that runs inside the runtime, after every turn, without anyone asking. Read its source and you find a loop that looks startlingly familiar: act, reflect on what happened, fold the lesson into a durable store, carry it into the next session.
That is the back half of ADD, implemented in code instead of in a methodology. This piece reads Hermes’ actual loop, maps it onto ADD’s eight steps, and draws the honest line: what putting the loop in the runtime proves, what it still cannot do, and why the runtime loop and the process loop are not rivals — they stack.
ADD’s loop, in one paragraph
ADD moves a feature through eight steps that never change: Ground → Specify → Scenarios → Contract → Tests → Build → Verify → Observe. The first seven run forward. Observe is the one backward arrow — it points from production back to Specify, and that single arrow is what turns a tidy waterfall into a loop. The forward steps constrain the what before the agent builds. The backward step folds what reality taught into the next pass, so the second loop starts from firmer ground than the first. The front half is about not building the wrong thing; the back half is about getting permanently better at building the right one.
Hold that split — front half constrains, back half compounds — because it is exactly where Hermes lands on one side and not the other.
Hermes’ loop, read from the source
Hermes runs an ordinary agentic tool-calling loop: a turn is some number of tool iterations until the agent produces a final response. The interesting part is what happens after the response ships. From agent/conversation_loop.py:
# Track memory nudge trigger (turn-based, checked here).# Skill trigger is checked AFTER the agent loop completes, based on# how many tool iterations THIS turn used....# Background memory/skill review — runs AFTER the response is delivered# so it never competes with the user's task for model attention.if final_response and not interrupted and (_should_review_memory or _should_review_skills): agent._spawn_background_review( messages_snapshot=list(messages), review_memory=_should_review_memory, review_skills=_should_review_skills, )Two counters drive it. A memory review is turn-based: every N turns, Hermes pauses to curate what it should remember. A skill review is iteration-based: it fires when a turn burned enough tool calls to suggest a workflow worth keeping. Neither runs inline. Both are spawned after the user already has their answer — the design comment is explicit that the review “never competes with the user’s task for model attention.”
What gets spawned is a separate, deliberately constrained agent. From agent/background_review.py:
Spawns a daemon thread after each conversation turn that forks the agent to review and autonomously update memory/skills. The review agent inherits the parent’s runtime … but runs with a restricted tool whitelist (only memory and skill management tools). This implements the built-in learning loop that evaluates turn outcomes and updates the knowledge base.
This is the detail worth slowing down on. The reviewer is not the same agent in a reflective mood — it is a fork with a different job and a smaller toolbox. It cannot write code, call the network, or touch the task. Its only verbs are “update memory” and “manage skills.” Hermes has structurally separated doing the work from learning from the work, and given the second one its own pass.
And it knows when a turn is worth learning from. From the skills documentation:
An agent creates skills after successfully completing complex tasks (5+ tool calls), when it overcomes errors or dead ends, when its approach is corrected by the user, or when it discovers a non-trivial workflow.
Read those four triggers against ADD’s categories for what Observe watches — defects, surprises, and new needs — and they rhyme. “Overcomes an error or dead end” is a defect caught and worth remembering. “Approach corrected by the user” is a surprise: the spec in the agent’s head was wrong. “Discovers a non-trivial workflow” is a new capability earned by doing. Hermes has encoded, as runtime triggers, the same taxonomy ADD asks a human to apply at Observe.
Mapping the two loops
Laid side by side, the overlap is precise — and so are the gaps.
| ADD step | What it does | Hermes equivalent |
|---|---|---|
| Ground | Re-read the living foundation before acting | Memory recall + FTS5 session search with LLM summarization for cross-session context |
| Specify / Scenarios | Clamp the what; make it concrete | — no pre-build specification step |
| Contract | Freeze the interface; one human gate | — no frozen contract |
| Tests | Executable definition of done, red first | — no red gate before building |
| Build | Agent writes code, free on the how | Agentic tool-calling iterations — the same engine |
| Verify | Evidence gate; a human stands at the risk | — ships the response, then reflects after the fact |
| Observe | Watch reality against the spec | Background review thread evaluates the turn's outcome |
| Fold | Spec delta re-enters at Specify; human consolidates | skill_manage creates/refines skills; memory tool updates the foundation |
The bottom three rows — Build, Observe, Fold — line up almost cleanly. Hermes’ agentic iterations are ADD’s Build. Its background reviewer is Observe. Its skill_manage and memory writes are the Fold. The top of the table is where Hermes is simply silent: there is no Specify, no Contract, no red suite, no Verify gate. Hermes acts, then learns. ADD constrains, then acts, then learns.
That is not a knock on Hermes. It is a general-purpose assistant, not a software-delivery method — learning from what happened is precisely its job. But it tells you exactly which half of the loop each one owns.
What Hermes proves: the fold belongs in the runtime
ADD describes Observe-and-Fold as a human ritual. The agent emits a tagged spec delta — [SDD · open], evidence attached — and a person runs the consolidation at milestone close: gather the open deltas, group by competency, confirm each edit, append to the living foundation, bump the version. The post on Observe and Fold is emphatic that the agent “never consolidates its own. Consolidation is judgment, and judgment belongs to the person who owns the review.”
Hermes demonstrates that a lighter version of the fold can run continuously, in the runtime, with no human in the inner loop at all — and that doing so is cheap if you respect one constraint: the fold runs after delivery, never during. That single scheduling decision is what makes an always-on learning loop affordable. The user never waits on it; it competes with nothing; if it fails, the failure is best-effort and the task is already done. The expensive version of “reflect on every turn” would be unusable. Hermes makes it usable by moving it off the critical path.
There is a second proof here, quieter but real. Hermes folds into two stores, not one: memory for facts and decisions, skills for reusable workflows. That is the same split ADD draws between PROJECT.md — the living foundation of domain language and settled decisions — and CONVENTIONS.md — the tagged, inherited record of how to build in this codebase. A skill that “self-improves during use” and is recalled by name on the next relevant task is the runtime cousin of a convention folded once and inherited by every later milestone. Both systems independently discovered that what is true and how we work want different homes.
What Hermes can’t do alone: the front half
Now the honest line. Hermes’ loop has no gate before it acts. It learns brilliantly from outcomes — but it has no Contract to freeze, no red suite that must fail for the right reason before any code is written, no Verify step where evidence, not plausibility, decides whether the work is trusted. For a conversational assistant, that is the correct trade. For shipping production software, it is the exact gap ADD exists to close.
Two artifacts from real ADD projects show what the front half catches that no amount of after-the-fact learning would:
- In
ai-proxy(a 23-milestone, 120-task, six-day build), live verification through the real TLS edge surfaced two production defects that a 326-test unit suite had passed clean. The Verify gate — running the thing for real, not just green-lighting the suite — is what caught them. A learning loop that reflects on shipped turns never gets the chance: by the time it reflects, the defect already shipped. - In
scla-mono, a refute-read at the test gate caught two vacuous greens — a test that imported nothing and a filter assertion that asserted nothing. Both passed. A loop that trusts a green suite would have folded a false lesson (“this works”). ADD’s insistence that tests fail for the right reason first is what kept the foundation honest.
These are front-half saves. They happen before the agent’s work is trusted, which is the one place Hermes’ loop does not reach. And there’s a governance difference that compounds: Hermes’ background reviewer curates memory and skills on its own judgment — appropriate for a personal assistant. ADD deliberately refuses that for shipped systems: the agent proposes open deltas; a named human consolidates. When the artifact is software other people depend on, who is accountable for the lesson is part of the lesson.
They stack
Put the two next to each other and the relationship is not which loop — it’s which layer.
| Layer | Owned by | What it covers |
|---|---|---|
| Front half | Process (ADD) | Ground → Verify: constrain the what, freeze the interface, gate the build on evidence. The half Hermes lacks — and the half production software cannot skip. |
| Build | Shared engine | An agent writes code through tool-calling iterations, free on the how. Identical in both; the same model, the same generation. |
| Back half | Runtime (Hermes) | Observe and Fold, automated: a forked, tool-restricted reviewer runs after delivery and writes lessons into memory and skills. Hermes proves this can be continuous and cheap. |
The future that’s interesting isn’t ADD or a self-improving agent. It’s ADD’s gated front half — frozen contract, red suite, evidence gate, human-owned consolidation — wrapped around a runtime whose back half already folds lessons into durable memory and skills on its own. The process supplies the constraints the runtime has no opinion about; the runtime supplies the always-on fold the process asks a human to do by hand. Hermes shows the back half can live in the agent. ADD shows why the front half can’t.
The loop, it turns out, doesn’t have to live in only one place. The question is which half you let the runtime own — and which half you keep your hands on.
Related: How ADD Fixes the AI-Era SDLC names the method; Observe and Fold is the back half in full; Method vs. Mode does the same comparison for Claude Code’s Plan Mode. Hermes Agent source: nousresearch/hermes-agent.