SKILLS, PARALLELISM, AND COORDINATED TEAMS

7. Loop Bodies, Reusability, and the Skill Abstraction

A loop’s cadence (when it fires) and its body (what it does each cycle) are independent design axes. The reusable unit of “what it does” is best encoded as a versioned, composable artifact — a command or skill definition — rather than a prompt retyped from memory each time. This has direct platform implications: a body encoded this way is drivable interchangeably by an interactive session, a scheduled task, or a managed routine without modification; it travels with the repository under version control; and improving it once improves every loop that references it.

A workable body template follows an assess → act → verify → repeat-or-stop rhythm, with two properties that repeatedly separate reliable loops from runaway ones:

• An explicit stop condition, distinct from and in addition to a hard cycle cap. “Keep going” with no completion clause is a structurally unbounded process.
• A tightly scoped invocation, since an over-broad target (“fix the codebase”) inherits every failure mode of a vaguely-written goal condition — it is simply unbounded work wearing a schedule.

The maturity path for any loop body worth productionizing is: prototype interactively in a session → promote to a scheduled task for regular use → promote to a fully managed, terminal-independent routine once it has proven reliable and does not need supervision. Enterprises should resist starting new automation directly at the most decoupled surface; the promotion path exists precisely to surface failure modes while the blast radius is still small.

8. Parallelism, Isolation, and Fan-Out

Running multiple agents concurrently against a shared codebase creates exactly the collision risk that concurrent human edits to a shared file would create. The architectural answer, familiar to any engineering organization, is isolation: each concurrent agent operates in its own working copy (a git worktree, in the version-control-native case), converges its output as a branch and pull request, and merges only through the normal human-reviewed path.

For genuinely parallelizable, repetitive work — the same operation applied once per unit across a large population, such as a mechanical migration across hundreds of files or services — fan-out orchestration can scale this pattern to dozens or hundreds of concurrent isolated agents, each producing its own PR. This is the pattern to reach for when the work is “embarrassingly parallel”: the same transformation, repeated many times, with no cross-unit dependency.

A more advanced and still-maturing pattern is coordinated agent teams: a lead session that spawns named teammates, each a full independent agent instance with its own context, sharing a task list and a mailbox for direct coordination — as opposed to subagents, which only ever report back to a single caller. This unlocks genuine multi-agent coordination (a backend agent and a frontend agent negotiating a shared contract, with a third agent acting purely as reviewer) but comes at materially higher token cost and with real operational sharp edges — team state can lag, and coordination overhead is not free. Reach for it only when the work genuinely requires cross-agent negotiation; for independent parallel work, isolated worktrees are simpler, cheaper, and easier to reason about.