You built your first five agents. They each do their job. Then you build the sixth and seventh, and one morning you wake up to find your competitor-monitoring agent and your weekly-report agent both pulled the same data, synthesised it differently, and produced two conflicting summaries. Your listing-optimization agent updated copy at 6am. Your A+ content agent overwrote it at 6:15am. Nobody told you until a client asked why their hero image caption said something completely different from the bullet points.
That is the AI agent orchestration problem. And if you are running more than a handful of agents, you have already hit it — or you are about to.
I run 30+ agents across four ventures. I have no orchestration platform. No LangGraph. No CrewAI instance. No message queue. What I do have is a set of coordination patterns that took me six months of production failures to learn. This post is those patterns, stripped of the theory and vendor sales pitches.
What Is AI Agent Orchestration?
AI agent orchestration is the practice of coordinating multiple autonomous AI agents so they work together without duplicating effort, overwriting each other's output, or losing context between handoffs. It defines who runs when, who gets whose output, and what happens when two agents need the same resource.
It is not the same as scheduling, which is about when an agent runs. It is not the same as agent workflows, which are about the steps within a single agent run. Orchestration is the layer above both: the coordination between independent agents that share a business context.
Think of it this way. Scheduling is the alarm clock. A workflow is the morning routine. Orchestration is the system that stops your morning routine from colliding with your partner's when you both need the bathroom at 6:45am.
Why AI Agent Orchestration Breaks at Ten Agents
One agent is a tool. Five agents are a team. Ten agents are a coordination problem. Here is what actually breaks.
Duplicate work. Two agents pull the same data source, process it independently, and produce competing outputs. Your ad-spend monitor and your weekly P&L agent both query the same Amazon Advertising API, calculate ACOS differently because they use different date ranges, and give you two numbers. You spend 20 minutes reconciling instead of the zero minutes the automation was supposed to save you.
Context loss between handoffs. Agent A produces a competitor analysis. Agent B is supposed to use that analysis to write ad copy. But Agent B does not know where Agent A put the output, what format it used, or that it ran at all. So Agent B works from stale context — or worse, from no context — and produces copy that ignores the competitive insight you just paid tokens to generate.
Race conditions on shared resources. Two agents try to update the same listing within minutes of each other. Two agents read the same context file, both decide it needs updating, and the second write overwrites the first. Two agents hit the same API and one gets rate-limited, silently producing empty output that cascades through everything downstream.
None of these are theoretical. I have hit all three in production, some of them more than once. The fix is not more sophisticated tooling. The fix is patterns.
Four AI Agent Orchestration Patterns That Actually Work
After running multi-agent systems for over a year, I have settled on four orchestration patterns that cover every coordination scenario I encounter. You do not need all four on day one. Most operators start with the first two and add the others as their agent count grows.
Pattern 1: The Supervisor
One agent acts as a coordinator. It receives a task, breaks it into subtasks, dispatches them to specialist agents, collects their outputs, and assembles the final result. The specialist agents never talk to each other directly.
I use this for my weekly business review. A supervisor agent kicks off at 7am on Monday. It calls a revenue agent (pulls Seller Central numbers), an ad-performance agent (pulls advertising data), a content-health agent (checks listing scores), and a competitive-intelligence agent (checks competitor pricing and BSR). Each returns a structured JSON block. The supervisor stitches them into one briefing document with cross-references.
The supervisor pattern works when the subtasks are independent and you need a unified output. Its weakness is that it creates a single point of failure: if the supervisor breaks, everything breaks. Keep the supervisor logic simple — routing and assembly, not analysis.
# supervisor-briefing.md (skill file)
You are the Monday briefing supervisor.
Run these agents in order, collect their JSON output:
1. /revenue-pull → revenue.json
2. /ad-performance → ads.json
3. /content-health → content.json
4. /competitive-intel → competitors.json
Read all four JSON files.
Produce a single briefing document with these sections:
- Revenue summary (from revenue.json)
- Ad performance (from ads.json, cross-referenced with revenue)
- Content health (from content.json)
- Competitive moves (from competitors.json)
Flag any metric that changed more than 15% week-over-week.
Pattern 2: The Pipeline
Agents run in a fixed sequence. Agent A's output becomes Agent B's input. Agent B's output becomes Agent C's input. No branching, no parallel execution.
My content pipeline works this way. A research agent finds trending topics and competitor gaps. A drafting agent reads that research and writes a first draft. A review agent reads the draft against my style guide and brand rules, flags issues, and suggests edits. A formatting agent applies the final structure and metadata.
Pipelines are dead simple to debug because you can inspect the handoff artifact between each stage. If the final output is wrong, you trace backward through the chain until you find the stage that broke.
Implementation: each agent writes its output to a dated file with a stage prefix. The next agent reads from the previous stage's file.
# content-pipeline.sh
DATESTAMP=$(date +%Y-%m-%d)
PIPELINE_DIR="$VAULT/pipelines/content/$DATESTAMP"
mkdir -p "$PIPELINE_DIR"
# Stage 1: Research
claude -p "Run /content-research" > "$PIPELINE_DIR/01-research.md"
# Stage 2: Draft (reads stage 1)
claude -p "Read $PIPELINE_DIR/01-research.md. Run /content-draft" > "$PIPELINE_DIR/02-draft.md"
# Stage 3: Review (reads stage 2)
claude -p "Read $PIPELINE_DIR/02-draft.md. Run /content-review" > "$PIPELINE_DIR/03-review.md"
# Stage 4: Format (reads stages 2+3)
claude -p "Read $PIPELINE_DIR/02-draft.md and $PIPELINE_DIR/03-review.md. Run /content-format" > "$PIPELINE_DIR/04-final.md"
Pattern 3: Parallel Fan-Out
Multiple agents run simultaneously on independent tasks, and their outputs are collected when all have finished. Unlike the supervisor, there is no coordinator agent — the orchestration is in the shell script or cron setup.
I use this for my morning data pulls. Six agents run in parallel: Seller Central revenue, advertising metrics, inventory levels, review monitoring, competitor pricing, and customer message triage. They all write to the same date-stamped directory. A final synthesis agent runs only after all six have completed, reads the directory, and produces my morning briefing.
# morning-pull.sh
DATESTAMP=$(date +%Y-%m-%d)
PULL_DIR="$VAULT/daily-pulls/$DATESTAMP"
mkdir -p "$PULL_DIR"
# Fan out — all run in parallel
claude -p "Run /revenue-pull" > "$PULL_DIR/revenue.json" &
claude -p "Run /ad-metrics" > "$PULL_DIR/ads.json" &
claude -p "Run /inventory-check" > "$PULL_DIR/inventory.json" &
claude -p "Run /review-monitor" > "$PULL_DIR/reviews.json" &
claude -p "Run /competitor-prices" > "$PULL_DIR/competitors.json" &
claude -p "Run /message-triage" > "$PULL_DIR/messages.json" &
# Wait for all to finish
wait
# Synthesize
claude -p "Read all JSON files in $PULL_DIR. Run /morning-briefing" > "$PULL_DIR/briefing.md"
The wait command is the entire orchestration layer. That is not a joke. Bash parallelism with a barrier is all you need for fan-out/fan-in when the agents are independent.
Pattern 4: Event-Driven
An agent runs only when a specific condition is met. The trigger is not a schedule — it is a state change detected by another agent or a monitoring script.
I use this for my review-response agent. A lightweight monitoring script checks for new negative reviews every hour. When it finds one, it triggers the full review-response agent, which reads the review, pulls relevant product data, drafts a response, and queues it for my approval. No new negative review, no agent run, no tokens spent.
# review-trigger.sh (runs hourly via cron)
NEW_REVIEWS=$(claude -p "Run /check-new-negative-reviews --output count")
if [ "$NEW_REVIEWS" -gt 0 ]; then
claude -p "Run /draft-review-responses"
fi
Event-driven orchestration is the most cost-efficient pattern because idle time costs zero. But it requires a reliable detection mechanism — if the trigger misses an event, the downstream agent never runs.
How I Coordinate 30 Agents with Flat Files
Enterprise orchestration uses message queues, event buses, and service meshes. I use a directory structure and naming conventions. Here is the actual architecture.
Shared vault directory. Every agent reads from and writes to the same Obsidian vault. The vault is the shared state layer. No database, no Redis, no API — just markdown files and JSON in a directory tree that every agent can access.
Naming convention for handoff files. Every agent output follows the same pattern: {date}/{agent-name}-{output-type}.{ext}. This means any agent can find any other agent's output by convention alone. No registry, no service discovery.
vault/
daily-pulls/
2026-09-12/
revenue-pull-summary.json
ad-metrics-report.json
competitor-prices-snapshot.json
morning-briefing.md
pipelines/
content/
2026-09-12/
01-research.md
02-draft.md
03-review.md
04-final.md
agent-state/
last-run-times.json
lock-files/
Lock files for conflict prevention. Before an agent writes to a shared resource, it checks for a lock file. If the lock exists, the agent waits or skips. When it finishes writing, it removes the lock. This is the same pattern Unix daemons have used for decades.
LOCK="$VAULT/agent-state/lock-files/listing-update.lock"
if [ -f "$LOCK" ]; then
echo "Listing update in progress. Skipping."
exit 0
fi
touch "$LOCK"
# ... do the work ...
rm "$LOCK"
Execution order via cron timestamps. Agents that must run in sequence get staggered cron times. The data-pull agents run at 6:00am. The synthesis agent runs at 6:30am. The briefing-delivery agent runs at 7:00am. The 30-minute gap is intentional — it absorbs the variance in API response times and token generation speed.
This entire system runs on a Mac mini. The monthly infrastructure cost is $0 beyond the electricity and the API tokens. The total lines of orchestration code across all 30 agents is under 200 lines of bash.
Agent-to-Agent Handoffs: Passing Context Without Losing It
The handoff between agents is where most orchestration systems leak quality. Agent A knows everything about the problem. Agent B starts cold, with only whatever Agent A chose to write down. If Agent A's output is a wall of prose, Agent B has to re-parse and re-understand it. If Agent A's output is too terse, Agent B fills the gaps with hallucination.
The fix is structured handoff artifacts.
Every handoff file in my system has the same skeleton:
{
"agent": "competitor-monitor",
"timestamp": "2026-09-12T06:15:00Z",
"run_id": "comp-20260912-0615",
"status": "complete",
"summary": "3 competitor price changes detected",
"data": {
"changes": [
{
"competitor": "BrandX",
"asin": "B0XXXXXX",
"old_price": 29.99,
"new_price": 24.99,
"change_pct": -16.7
}
]
},
"errors": [],
"next_action": "Review pricing strategy for affected ASINs"
}
The downstream agent does not need to interpret prose. It reads structured data, checks the status field, and processes the data array. If the status is "error", the downstream agent knows to skip or escalate without trying to parse a failure message out of freeform text.
This pattern — structured JSON handoffs with metadata — eliminates 90% of the context-loss problems I used to have. The remaining 10% come from agents that need qualitative judgment from a prior step, which I handle by including a summary field the downstream agent can use as supplementary context without depending on it for data.
Five AI Agent Orchestration Mistakes Operators Make
Mistake 1: Building the orchestration layer first. You do not need orchestration until you have agents that conflict with each other. Build agents one at a time. Run them independently. When two agents start stepping on each other, add the minimum coordination needed. Orchestration is a response to observed problems, not a prerequisite.
Mistake 2: Using a framework when a shell script would do. LangGraph, CrewAI, AutoGen — they all solve real problems for teams building complex multi-agent applications. But if your orchestration needs are "run these five things in order" or "run these six things in parallel and then run one more thing," a bash script with wait is simpler, faster to debug, and has zero dependencies. Match the tool to the actual complexity.
Mistake 3: Letting agents communicate through natural language. When Agent A sends Agent B a paragraph of text, you have introduced an interpretation step that can fail in subtle ways. Structured data — JSON with explicit fields — removes ambiguity. Save the natural language for the final output that humans read.
Mistake 4: No conflict-resolution strategy. What happens when two agents try to update the same listing? What happens when one agent's output contradicts another's? If you do not have an explicit answer, the answer is "whoever runs last wins," which is the worst possible coordination strategy. Define your conflict rules before you need them.
Mistake 5: Ignoring execution-time variance. Your agents do not always take the same amount of time. API latency varies. Token generation varies. A pipeline that assumes Stage 1 always finishes in under 5 minutes will break the morning it takes 12. Build in buffer time for sequential dependencies, or use explicit completion checks instead of time-based assumptions.
Frequently Asked Questions
Do I need an orchestration platform like LangGraph or CrewAI?
Not at the scale most operators work at. If you are coordinating 5-30 agents with clear inputs and outputs, shell scripts, cron scheduling, and flat files handle the orchestration cleanly. Platforms add value when you need dynamic routing (the orchestrator decides at runtime which agent to call), complex error recovery, or a visual UI for non-technical team members. For a solo operator or lean team building on Claude Code, the overhead of a platform exceeds the benefit until you are past 50+ agents with interdependent decision trees.
What is the difference between orchestration and a workflow?
A workflow is the sequence of steps within a single agent run — "fetch data, analyse it, write a report, send it." Orchestration is the coordination between separate agent runs — "the revenue agent and the ad agent both need to finish before the briefing agent starts, and neither should overwrite the other's data." Workflow is intra-agent. Orchestration is inter-agent.
How do I handle failures in a multi-agent pipeline?
Every agent should write a status field in its output: "complete," "partial," or "error." Downstream agents check that field before processing. If an upstream agent errors, the downstream agent either skips (for non-critical inputs) or reports the gap in its own output. I also keep the last successful run's output in place, so a failed run does not delete yesterday's good data. For critical pipelines, I add a dead-simple alerting step: if the synthesis agent finds an error status in any input, it sends me a notification before producing the briefing.
How do I debug when the final output is wrong but all individual agents look fine?
Trace the handoff artifacts. Read each intermediate file in the pipeline and check whether the data that arrived at each stage matches what the previous stage actually produced. Nine times out of ten, the problem is either a stale file (the downstream agent read yesterday's output instead of today's) or a structural mismatch (the upstream agent changed its output format and the downstream agent still expects the old shape). Timestamped file paths and structured JSON make both problems visible in seconds.
When should I switch from sequential to parallel orchestration?
When your total pipeline time exceeds your patience threshold and the agents are genuinely independent. If Agent B needs Agent A's output, they must run sequentially. If Agent A and Agent C both pull from external APIs and neither needs the other's result, running them in parallel cuts your wall-clock time in half with zero additional complexity — just add & to the bash commands and wait at the end.
The Three Things to Do This Week
AI agent orchestration does not require a platform, a framework, or a systems-engineering degree. It requires patterns.
First, audit your existing agents for overlap. List every data source each agent reads from and every output location each agent writes to. If two agents share an input or an output, that is your first orchestration point.
Second, adopt structured handoff artifacts. Pick one pipeline where Agent A feeds Agent B and replace the freeform text handoff with a JSON file that has explicit fields for status, data, and next action. Watch how much easier debugging becomes.
Third, write your execution order down. Whether it is a cron schedule, a shell script, or a whiteboard — document which agents depend on which other agents' output. That dependency map is your orchestration architecture. Everything else is implementation detail.
AI agent orchestration at the operator scale is not about building infrastructure. It is about making the agents you already have stop fighting each other — and start compounding.