most “multi-agent” demos are theater. a swarm of bots spawning bots, a diagram with twelve arrows, and no way to run the same thing twice.

so when we added multi-agent to the loops spec, we made it boring on purpose.

a multi-agent loop is an ordered chain of role-prompts with a structured handoff. that’s the whole thing. no process swarm, no orchestration magic in the file. and because the file only describes the chain, the exact same one runs on a plain model CLI or on a full 5dive runtime without changing a byte.

what shipped

section 4 of the loops spec, agents:. it’s live at agenticloops.dev/SPEC.md and in the open repo, github.com/5dive-ai/loops.

most loops are one agent doing one job on a timer. some jobs are a pipeline. a researcher gathers what changed, a writer turns it into a briefing, a publisher posts it. you write that as an ordered list of roles under agents:, still one file, one trigger, one scheduled run:

agents:
  - role: analyst
    skills: [deep-research]
    prompt: |
      scan our competitor set for the last interval. return a
      structured list of what changed, with sources. no prose.
  - role: writer
    skills: [copywriting]
    prompt: |
      from the analyst's findings below, write a sourced briefing
      of what changed and what it means, then post it to the team.
      findings:
      {{previous_output}}

roles run in array order, strictly in sequence. each one gets the previous role’s output injected wherever you write {{previous_output}}. the first role gets none. that’s it.

the boring part is the point

here’s the line we care about: the spec says what a multi-agent loop is, and never how a host runs it.

the simplest thing that satisfies it is a for-loop over prompts. run role one, capture its output, run role two with that output pasted in. no processes spawned at all. any harness with a scheduler can do that, shelling out to whatever model CLI you have, claude -p, codex exec, whatever’s on the box.

a host with real orchestration can do more. on a 5dive runtime, each role runs as its own linked task with its own clean context, handing off a structured result. cleaner, and it opens the door to parallel roles in a later spec.

both are correct. both satisfy one observable contract: role N sees role N-1’s structured output. nothing about how it ran leaks into the file, so the LOOP.md is byte-identical across them. write it once, and it’s portable to a laptop cron job or a fleet you never touch.

the one hard rule

the handoff is structured, not chat.

each role’s output passes to the next as a defined artifact, injected at {{previous_output}}. never transcript scraping, never “read the last thing the other agent said and hope.” that’s the single requirement in the whole section, and it’s the one that makes an unattended run come out the same way every time no matter where it runs.

we’re being straight about the edges. v0.1 is sequential only, no branching or parallel fan-out yet. the run carries a single-signer receipt for now, one signature over the whole chain. per-handoff co-signed edges, where each role signs what it passed on, are v0.2.

try it

install any loop into your own harness:

npx agenticloops install <owner/repo> --harness=5dive

or read section 4 and write your own chain. intel-brief in the repo is a real one you can crib from.

the spec’s the contract. where each role actually wakes up is your business, and that’s exactly how we wanted it.

the whole thing is open. the spec, schema, and every loop live at github.com/5dive-ai/loops, and the 5dive CLI that runs them on your own box is open too, at github.com/5dive-ai/5dive. read section 4, fork it, open a PR.

want the whole thing running unattended on a box that’s yours? that’s 5dive.