Agents, swarms & flows

One idea, three altitudes: an agent does a job, a swarm is agents plus process plus proof, and a flow makes the whole thing run on a schedule. Start here before the deep chapters.

An agent is a worker with a job description

An agent is a model given a role: a Developer, an Analyst, a Security Auditor. The role sets what it is for, what it is allowed to touch, and what good output looks like. On its own an agent is useful the way a capable contractor is useful: hand it a scoped task in chat or in a flow and it does the work, under your content policy, with its cost metered.

But a single agent has the weaknesses of a single worker. It grades its own homework. It has no reviewer, no second opinion, and no one checking the work against what you actually asked for.

Agents + process + quality = a swarm

A swarm is what you get when you stop hiring one contractor and staff a team. Three ingredients, and each one earns its place:

  • →The agents: a composed crew of roles matched to the brief - analysts for an analysis, developers and reviewers for code, plus Oversight seats for security and compliance. Each seat has a reason on the record.
  • →The process: phases. The crew plans before it builds, builds before it reviews, and reviews before anything is called done. Plans wait at approval gates; you see the work before it spends.
  • →The quality: a Definition of Done that you set, verified by a review strategy - rotating agents proving each other's work against your criteria. Done is a judgment enforced by the system, not a feeling the team reports.

That is the whole trick: process turns parallel workers into a pipeline, and the quality gate turns output into a deliverable. A swarm does not finish when the agents stop typing; it finishes when the work passes the bar you wrote.

A composed swarm crew: role chips with a stated reason, Oversight seats, and the receipt footer
↳The team, the reasoning, and the price - before anything runs.

Flows make it repeatable

A swarm is a project: you brief it, gate it, and receive the deliverable. A flow is what you build when that work should happen every week without you. Flows are graphs of nodes on a canvas, and agents and swarms are node types in that graph: a single Agent node scores each vendor inside a loop, a Swarm node runs the full deep-dive team as one step, and Human nodes pause the run wherever a person must sign off.

The trigger replaces you kicking things off: a schedule, a manual run, or an external event. The trace replaces you keeping notes: every run records what each node did, which branch the decision took, and who approved the gate. Same governance, zero momentum: an unattended run still stops at every human checkpoint you drew.

A flow canvas chaining a schedule trigger, HTTP fetch, an agent scoring loop, a decision to a swarm deep-dive, a human gate, and a report
↳The ladder in one picture: agents and a swarm as steps in an automation, with a human gate where it matters.

Pick your altitude

  • →A question or a document: chat with one model, no ceremony.
  • →A task with a clear scope: a single agent, in chat or as a flow node.
  • →An outcome that must be right: a swarm, with a Definition of Done and review.
  • →Work that recurs: a flow, with agents and swarms as its workers and humans at the checkpoints.

Everything below this page is the deep end: the role census, the launch modal, plan gates, the flow node vocabulary, and run traces. Each chapter assumes this mental model.