Agent pipelines

The multi-agent chains stage by stage — the products pipeline, the two video trios, and the intelligence desk fan-out.

Some deliverables are too large for one agent to hold well — a full knowledge product, a produced video, a day's intelligence output. Command Center runs that work as pipelines: chains of single-purpose specialists, coordinated mechanically by the automation daemon, with your approvals between the stages that matter. This page explains the shape those chains share, then walks each one stage by stage.

The shape every chain shares

Four design rules repeat across all of them:

One concern per stage. Each agent in a chain owns exactly one transformation — survey, outline, research, refine, render. It is never asked to also do the next stage's job.
Fresh context per stage. Every stage runs as a newly spawned session that reads only its own inputs. Nothing drifts or leaks from one stage to the next; a stage can be re-run in isolation at any time.
Files are the contract. A stage's output is a document on disk — an outline, a manifest, a storyboard, a proposal. That file is what the next stage reads and what you review. If you can read the file, you know the state of the pipeline.
The daemon does the bookkeeping. Sequencing, dispatch, claiming, timeouts, retries, and output paths are handled mechanically by the automation engine — agent attention is spent on judgment, never on coordination.

Your role is the editorial one: you trigger stages from the relevant view, read the artifact each stage produced, and approve, edit, or re-dispatch before the chain moves on.

The products pipeline

The longest chain in the platform: it turns a folder of source material into a finished two-part knowledge product — a dense agent-facing reference set plus a human-facing manual. You drive it from the Products view; every stage is a button, and the chain never advances without you.

Stage	Agent	Reads	Produces
1 · Sight	`product-sighter`	Every seed document	A structured topic map of what the sources contain
2 · Compose	`product-composer`	The topic map	A proposed product outline for you to adopt or edit
3 · Research	`product-research-scout`, then `product-researcher`	The topic map and coverage state; then the scout's manifest	A reading plan; then one file of deduplicated, build-ready section knowledge
4 · Consolidate	`product-consolidator`	Research notes you select	One merged artifact preserving every unique insight
5 · Audit	`product-auditor`	The latest version of every section	A cross-section overview: duplication ownership, off-voice wording to scrub, flow notes
6 · Refine	`product-scope-refiner`	One section's notes plus references you attach	The near-final section itself, densified and gap-filled
7 · Finalize	`product-section-finalizer`	The refined section plus the audit overview	The final agent-facing section
8 · Human author	`product-human-author`	One finalized section at a time	The matching chapter of the human-facing manual, with optional imagery
Cover	`product-illustrator`	The product's scope and key sections	The cover-image prompt the local image daemon renders

Points worth knowing:

Scope approval is the hard gate. After research, you review and approve the scope before any drafting happens — the outline you sign off is the contract the later stages honor.
Sections move independently. Refine, finalize, and human-author all run per section, so you can push one chapter to done while another is still in research. Earlier versions are kept — refinement writes new revisions, never overwrites.
The splitter design pays off at review time. Because the researcher writes in the product's own voice with sources listed once at the bottom, and the auditor hunts residue across sections, what reaches you at stage 7 is close to shippable.

The video pipelines

Both video engines use the same three-beat editorial shape — direction → plan → execution — with knowledge deliberately narrowing at each step. The first agent knows only capability categories, the second knows the catalog by name, and only the third holds the deep authoring surface. That narrowing is why each stage stays sharp: no agent carries context it does not need.

The Remotion trio

Stage	Agent	What it does
1	`video-brief-author`	Reads your freeform brief and enriches its creative hints — core metaphor, color arc, key moments, tone reference — written back onto the brief itself
2	`video-script-author`	Turns the enriched brief into a scene-by-scene production script: which composition, which animations, which helpers realize each scene
3	`video-composer`	Authors the schema-correct render proposal plus a readable walkthrough explaining every choice

You review the proposal and walkthrough in the Video view, then dispatch Produce to render — or send the composer back around with edit instructions. Iteration is a first-class path, not an exception.

The HyperFrames trio

Stage	Agent	What it does
1	`hyperframes-brief-author`	Reads the brief plus every reference you attached — URLs, files, site captures — and replaces it with a denser, reference-aware version. There is only ever the brief; each pass tightens it
2	`hyperframes-planner`	Authors the storyboard: per-beat mood, camera, assets, exact registry-block picks, transitions — plus a machine-readable sidecar listing what to install
3	`hyperframes-html-author`	Installs the planned blocks, writes all the composition HTML, wires the animation timelines, then lints and inspects its own output and fixes findings before it finishes

The storyboard is the artifact to read between stages 2 and 3 — it is the whole creative plan in one document, and editing it redirects the build.

Feeding the pipelines: footage preparation

footage-editor sits upstream of both engines. Give it one raw clip and a natural-language instruction and it transcribes, removes fillers and dead silence, grades, trims, and renders a prepared version into the project's assets — so the authoring trios always start from clean material. It prepares clips only; captions and animation belong to the pipelines themselves.

The intelligence desk fan-out

The news pipeline runs on a scout-then-fan-out pattern rather than a fixed chain, because the number of outputs varies with the news itself:

Digest. On schedule, observer-agent runs turn freshly harvested items into observer reports, batch by batch.
Scout. A scout agent (news-scout for briefings, report-scout for deep-dive reports) reads the pooled reports and proposes story clusters — it decides nothing downstream.
Validate and fan out. The daemon validates the proposals, caps the count, and spawns one fresh writer session per cluster — each news-writer or report-writer run sees only its own cluster's sources. Clean context per story is what keeps briefings grounded in their actual sources.
The specialist lanes. Alongside the cluster fan-out: breaking-writer extracts short ticker items from the freshest reports, deduplicated against the last 72 hours; roundup-writer produces the weekly multi-topic synthesis; news-illustrator composes hero-image prompts for new articles; news-translator writes native-quality locale siblings for published pieces; yt-video-analyzer turns harvested videos into frame-anchored deep analyses.
The outbound gate. newsletter-writer curates the email digest — and stops. Drafts are always written with a pending status; sending is a separate, explicit action you take. No schedule, retry, or configuration weakens that.

You steer this pipeline through its routines: which batches feed which writers, how often each lane runs, and which lanes run at all are all cadence and configuration decisions you own.

Why the chains are split this way

The pipelines look elaborate until you try to collapse one. A single agent asked to research, outline, draft, audit, and polish a product accumulates a long, drifting context and produces its worst work at the end — exactly where quality matters most. Splitting by concern keeps every stage near the top of its game, makes each intermediate artifact reviewable by you, lets cheap models carry mechanical stages while judgment stages get the strong one, and turns re-work into re-running one stage instead of starting over.

The same logic scales down: for work that fits one agent, use one agent. The delegation guide covers when a pipeline, a routine, a single dispatch, or a mission fleet is the right tool.

Where to go next

The agent roster — every family, including the pipeline members
Routines — the engine that schedules and dispatches these chains
Catalogs — flat tables of agents and routines

On this page