Multi-Agent Content Pipelines: Practical Orchestration Patterns

Running a content pipeline with AI agents sounds straightforward: tell the AI to research a topic, write an article, edit it, and publish. In practice, a single agent doing everything hits limits fast — context windows overflow, quality degrades across long sessions, and costs balloon as you pass everything through expensive models.

The solution is specialization. This post covers the orchestration patterns I use to run a multi-agent content pipeline — what works, what breaks, and how to manage costs at scale.

The Pipeline

The content pipeline has four stages, each handled by a different agent:

Scout (Research) → Writer (Content) → Editor (Review) → Publisher (Deploy)

Each agent is specialized:

Agent	Model	Tools	Purpose
Scout	Sonnet	Web search, fetch	Research topics, gather sources
Writer	Opus	File read/write	Create content from briefs
Editor	Opus	File read/write, diff	Review for quality, style, accuracy
Publisher	Haiku	Git, deploy tools	Format, commit, deploy

The coordinator dispatches work between stages and reviews output at each checkpoint. This is the opposite of end-to-end autonomy — every stage has human oversight before proceeding.

Why Specialize?

A single agent processing a 10-article batch will hit problems:

Context overflow: Research notes + drafts + revision history exhausts the context window. By article 7, the agent has forgotten the sources from article 1.

Quality degradation: Long sessions produce “drift” — the agent’s tone, structure, and focus shift subtly over time. Without editorial checkpoints, you end up with inconsistent content.

Cost inefficiency: Using Opus for everything is expensive. Research and publishing don’t need advanced reasoning — cheaper models work fine.

Specialization solves these:

// Cost optimization through model routing
const modelForTask = {
  research: 'claude-sonnet-4-5',    // Fast, capable, cheap
  writing: 'claude-opus-4-5',        // Best reasoning for content
  editing: 'claude-opus-4-5',        // Quality judgment matters
  publishing: 'claude-haiku-4-5'     // Simple mechanical tasks
};

The coordinator uses the cheapest viable model per stage. Opus only runs where judgment matters.

Pattern 1: Manifest-Based Dispatch

The naive approach sends file contents to agents:

// Bad: Content in dispatch
agent.dispatch({
  task: "Edit these articles",
  articles: [
    { content: "Full text of article 1..." },
    { content: "Full text of article 2..." },
    // ... context window fills up
  ]
});

This breaks at scale. Ten articles with source material easily exceeds context limits.

The better approach sends manifests — file paths and metadata, not contents:

// Good: Manifest dispatch
agent.dispatch({
  task: "Edit articles in the manifest",
  manifest: [
    { path: "/content/article-1.md", topic: "SEO basics", status: "draft" },
    { path: "/content/article-2.md", topic: "Link building", status: "draft" },
  ],
  instructions: "Read each file, apply style guide, save changes"
});

The agent reads files incrementally, processes each one, and moves on. Context usage scales linearly with task complexity, not input size.

This pattern comes from the Recursive Language Models paper (Zhang et al., 2025): treat data as environment, not context. The agent interacts with data through tool calls rather than holding it all in the prompt.

Pattern 2: Structured Returns

When a sub-agent completes work, what should it return?

The naive approach returns everything:

// Bad: Full output in return
return {
  status: "complete",
  article1: "Full edited text...",
  article2: "Full edited text...",
  reasoning: "3000 words of explanation..."
};

This pollutes the coordinator’s context. After five sub-agent calls, the coordinator can’t think clearly because its context is full of sub-agent output.

Structured returns solve this:

// Good: Summary return, details to files
return {
  status: "complete",
  summary: {
    processed: 10,
    changed: 7,
    skipped: 2,
    errors: 1,
    confidence: "high"
  },
  detailsPath: "/logs/batch-edit-2026-02-24.json"
};

The coordinator gets a summary to make decisions. Full details are written to a file, accessible if the coordinator needs to drill down but not cluttering context by default.

Pattern 3: Programmatic Loops

Processing 70 articles manually means:

"Do articles 1-10"
"Do articles 11-20"
"Do articles 21-30"
...

This is O(N) human supervision for O(N) work. It doesn’t scale.

The better approach: dispatch a coding agent to write a processing loop.

// Coordinator dispatches loop creation
agent.dispatch({
  task: "Write a script that processes all articles in /content/draft/",
  requirements: [
    "Read each .md file",
    "Apply edits per style guide",
    "Track progress to checkpoint file",
    "Handle errors gracefully",
    "Exit with summary report"
  ]
});

The coding agent produces a script that handles iteration, error recovery, and progress tracking. The coordinator runs the script and monitors completion, not individual items.

This is O(1) verbalized delegation producing O(N) programmatic work — the key insight from RLM’s symbolic recursion pattern.

What Goes Wrong

Orchestration patterns fail in predictable ways:

Agent drift: A writer processing 50 articles slowly changes tone. By article 50, the voice doesn’t match article 1. Solution: editorial checkpoints every 10-15 articles, comparing against reference examples.

Context rot: The coordinator accumulates state across many sub-agent calls. Eventually it starts making bad decisions because it’s confused by old context. Solution: start fresh context for each major phase; don’t try to maintain state across the entire pipeline.

Cascade failures: Editor rejects → Writer rewrites → Editor rejects again → infinite loop. Solution: kill conditions. After 2 revision cycles, escalate to human review.

// Kill condition for revision loops
let revisions = 0;
while (editorResult.status === "rejected" && revisions < 2) {
  revisions++;
  writerResult = await writer.revise(editorResult.feedback);
  editorResult = await editor.review(writerResult);
}

if (editorResult.status === "rejected") {
  escalate({ article: path, issue: "Revision loop", feedback: editorResult });
}

Cost Management

Multi-agent systems can burn money fast. Track costs per-agent, per-task:

// Cost tracking wrapper
async function tracked(agentName, task, fn) {
  const start = { tokens: getTokenCount() };
  const result = await fn();
  const cost = calculateCost(getTokenCount() - start.tokens, modelForTask[task]);
  
  log({ agent: agentName, task, cost, timestamp: Date.now() });
  
  if (cost > COST_THRESHOLD) {
    alert(`${agentName} exceeded cost threshold: $${cost}`);
  }
  
  return result;
}

Set kill conditions: “if this batch exceeds $5, stop and report.” Runaway agents can drain budgets in minutes.

Use the cheapest viable model per stage. System prompt tokens are amortized across the batch — processing 50 articles with one system prompt is cheaper than 50 separate calls.

Real Numbers

Some examples from actual pipeline runs:

70 articles translated (Indonesian → English):

Scout: Research terminology, gather glossary
Writer: Translation with localization
Editor: Quality check, consistency review
Total: ~$8, 4 hours elapsed (mostly parallelized)

SEO sprint across 157 pages:

7 specialized sprints, different focus each
Haiku for mechanical changes (meta descriptions)
Opus for substantive changes (content restructuring)
Total: ~$12 over 2 weeks

Daily diary (automated publishing):

Single cheap agent, scheduled cron
Minimal orchestration — one-shot task
Total: ~$0.02 per day

The pattern: complex pipelines are expensive but batch well. Simple recurring tasks are cheap per-run but add up over time.

Checklist for Multi-Agent Pipelines

Before dispatching any pipeline:

Map stages: What discrete steps does this work require?
Assign models: Cheapest viable model per stage
Define checkpoints: Where does human review happen?
Set kill conditions: Cost limits, revision limits, timeout
Plan context management: Manifest dispatch? Structured returns?
Build monitoring: How will you know if something breaks?

Orchestration complexity should match task complexity. Don’t build a four-agent pipeline for something a single call can handle. But don’t try to force a single agent through work that needs specialization.

Recursive Patterns for Scaling Agent Work — The research foundations for these patterns
Building a2alist.ai — Multi-agent pipeline built the verification system

Building content pipelines with AI agents. More on orchestration patterns at skillpacks.dev.