06-reference/concepts

Loop Engineering vs. Agent Brigade — anatomy mapping and honest gap-check

2026-07-04·concept·status: living·source: synthesis of two essays (see Citations)
agentsagent-brigadeloop-engineeringorg-designharness-engineeringcaf

Loop Engineering vs. Agent Brigade

June 2026's "loop engineering" moment (crystallized around Boris Cherny's "I don't prompt Claude anymore… my job is to write loops") produced two serious essays: Addy Osmani's practitioner anatomy ([[2026-07-04-addy-osmani-loop-engineering]]) and Armin Ronacher's cautious counterweight ([[2026-07-04-armin-ronacher-the-coming-loop]]). RDCO's Agent Brigade pattern (skill-agent-brigade plugin, ~/Projects/ray-plugins/plugins/skill-agent-brigade/) was designed independently and predates both essays. This note maps the loop-engineering anatomy onto the brigade's equivalents, credits where the brigade is genuinely ahead, and — honestly — flags where the essays surface something the brigade actually lacks.

The mapping table

Loop-engineering primitive Source Brigade equivalent Brigade ahead?
Trigger (a loop needs something that starts each run) Osmani's "Automations — the heartbeat" service start walk loop (pull-with-lease over the rail backlog) + steward-authored tickets as the unit that starts a build; cron-schedulable per deployment Roughly parity — both are "scheduled/recurring kickoff." Brigade's trigger is coupled to a durable queue (the rail), not a bare cron job.
Doer (the agent that does the work) Osmani's coding agent itself; the thing automations/skills/connectors all serve Stations — atomic skills, one phase/one concern each (spec-author, test-author, code-author, per-domain stations) Ahead. Loop engineering's "doer" is typically one agent wearing many hats across a session; the brigade decomposes the doer into named, individually-testable roles with a defined "type signature" (input params / accessible context / expected output) per station.
Checker (something that verifies the doer's output) Osmani's "Sub-agents — keep the maker away from the checker" Critic (N adversarial LLM axes, advises) + deterministic lint gate + execution-eval station (measures lift over base model) Ahead, materially. Osmani's pattern is binary (maker, checker). The brigade adds a third layer — the expo, who decides using a closed five-exit vocabulary (advance · refire-to-author · reroute-to-spec · reroute-to-steward · kill), holding cross-station/phase context a single-shot critic lacks. Neither essay describes anything like execution-eval's controlled A/B ablation (base model vs. base model + skill, N-sample, pass-rate ± stddev, lift must clear the noise band) — that is a genuine methodological step past "have a second agent check it."
Stop (how the loop knows it's done, or should pause) Implicit in both essays; Ronacher's caution is precisely about loops that don't have a good stop/human-check-in The exit set (advance/refire-to-author/reroute-to-spec/reroute-to-steward/kill) + escalate as a budget-stop pause on max_rounds, human-decided Ahead. This isn't a single "stop" — it's a closed, named disposition vocabulary enforced at a specific decision point (the expo), with an explicit escalation path to a human when the budget runs out. Far more structured than "the loop keeps going until something looks wrong."
Memory (state that persists across runs) Osmani's "State/memory" — markdown files, Linear boards, AGENTS.md, progress files The ticket itself — one append-only markdown file: identity + context manifest + ## Order + ## Resolved-context snapshot + ## Work log + ## Artifacts — plus the cellar as durable cross-ticket knowledge store Ahead. Osmani's memory layer is "some markdown files, maybe a Linear board" — ad hoc per practitioner. The brigade's ticket-is-the-build-record model is a formal contract (TICKET-CONTRACT.md), the same shape every time, auditable and re-runnable against known inputs.
Skills (reusable project knowledge, stop re-explaining context) Osmani's "Skills — stop re-explaining your project every session" Stations, literally — "an atomic skill / one phase / one concern" is the brigade's own definition of a station Parity, same word. This is the one primitive where the brigade and loop-engineering vocabulary are near-identical — both converged on "skill" as the unit of reusable capability.
Worktrees (filesystem isolation so parallel agents don't collide) Osmani's "Worktrees — so parallel doesn't turn into chaos"; git worktree as the concrete primitive (No direct equivalent found) Gap — see below.
Connectors (MCP-based real-world action, not just reporting) Osmani's "Plugins and connectors — the loop touches your real tools" The resolver port (typed context sources — file/url/mcp/qmd/cellar, per BUNDLE-SPEC.md) and the hexagonal ports frame (ticket contract / rail / resolver / cellar) Mostly ahead, one open question. The brigade already generalizes "connectors" into a typed, pluggable source-of-context abstraction rather than Osmani's flatter "plugins and connectors" bucket — MCP is just one resolver type among several. But see gap #3 below: the docs reviewed frame resolvers as read/context-acquisition, and don't show an explicit risk-tiering story for write-capable connector actions taken mid-build.

Where the brigade is ahead — summary

Beyond the per-row notes above, three brigade-level features have no analogue in either essay at all:

Where the essays expose a real brigade gap — honest accounting

Four items, each hedged to what was actually read (BRIGADE-INTERFACE.md, DESIGN.md, TICKET-CONTRACT.md) — absence from these three docs doesn't prove absence from the whole system, and is flagged as such:

  1. Worktrees / true filesystem parallelism. Real gap. BRIGADE-INTERFACE.md states the rail is currently "one-walker-enforced" (a rail-level service lock), with real multi-walker concurrency explicitly deferred ("P2/multi-walker" is future work, and the doc itself notes today's lock is "still advisory-grade — real atomicity arrives with an atomic rail adapter"). Osmani's worktrees pattern solves exactly the problem the brigade will hit the moment it moves to concurrent walkers: multiple agents mutating the same repo need filesystem isolation, not just a queue lock. Action-relevant: when P2/multi-walker work starts, git-worktree-style isolation per concurrent station run is a technique to borrow, not reinvent.

  2. No explicit disposability/longevity axis. Ronacher's sharpest distinction — loops work great for disposable/exploratory artifacts (ports, perf spikes, security scans), and are risky for code that needs to carry invariants long-term — has no named equivalent in the ticket contract. The current type_hint taxonomy (computational/corpus/generative/operational/advisory) sorts by what kind of reasoning the work needs, not by how much ceremony a given build deserves relative to its expected lifespan. A quick exploratory ticket and a load-bearing production skill get the same gates today. Minor but real — worth a design conversation, not urgent.

  3. Write-capable connector risk-tiering not visible in the docs reviewed. Osmani frames connectors as the moment a loop stops reporting and starts acting on real systems (merging a PR, sending a message) as a qualitatively different risk tier from read-only context gathering. The resolver/BUNDLE-SPEC types reviewed for this task (file/url/mcp/qmd/cellar) read as context-acquisition sources; nothing in BRIGADE-INTERFACE.md, DESIGN.md, or TICKET-CONTRACT.md as read here describes a gating policy specifically for MCP connections that can write (vs. ones that only read). This may well exist elsewhere in the vault or in a station's own SKILL.md and simply wasn't in scope for this pass — flagged as "not found in the three docs reviewed," not "confirmed absent."

  4. No token-budget / cost axis at the rail-ticket level. Osmani names token-cost discipline as a first-class loop-design concern. Execution-eval tracks tokens per skill-creator's aggregate_benchmark.py at the skill-eval layer, but none of the three docs reviewed describe cost-per-ticket or a Return-on-Tokens-style metric as an operating dimension of the rail itself — worth cross-referencing against [[2026-06-10-not-boring-return-on-tokens]], which raised the same gap independently for RDCO's own recurring crons.

Positioning for corporate education docs

Loop engineering = one doer + one checker. A single automation with a verification step: an agent runs, another agent (or the same one) checks its work, and some ad hoc markdown or a Linear board remembers where things stand. That's the whole shape, and for a solo practitioner it's often enough.

A brigade is what a loop grows into when the work needs roles, contracts, and an audit trail. Roles, because one doer stops being enough once a process has more than one kind of judgment call (spec vs. test vs. author vs. critic are different skills, not the same skill run four times). Contracts, because "the checker looked at it" doesn't scale past a team of one — a brigade enforces its input/output shape at a port boundary (Gate A) before any judgment call happens (Gate B), so the pass isn't relitigating "is this even a valid request" every time. And an audit trail, because "check the git history and hope" isn't a defensible answer when a client, a compliance reviewer, or a handoff needs to see exactly how a decision was reached — the ticket's append-only work log is that trail, not a reconstruction after the fact.

For CAF: teach loop engineering as the entry vocabulary — it's the frame clients will already have heard of via Cherny/Osmani, and it's the right frame for a single practitioner's single workflow. Teach the brigade as the production-grade evolution, positioned explicitly as "what you build when the loop needs to survive contact with more than one stakeholder."

Citations

Related