agent-orchestration
Skill0 starsChanged 38 days agoMITView on GitHub
Designs reliable multi-agent LLM systems - choosing a topology, writing handoff contracts between agents, deciding what runs in parallel vs series, and setting context, retry, and cost budgets that stop runaway loops. Use when someone asks "should I split this into multiple agents", "my agents keep looping", "how do I pass context between agents", "orchestrator vs pipeline vs router", or is architecting an agent workflow. Do NOT use for tuning a single prompt - use prompt-engineer instead; do NOT use for measuring agent output quality - use llm-evaluation instead; for making a product agent-operable end to end, use build-on-agent-native.
24 other projects use a version of this.
Adopted by
Most recently taken up by
- CassetteTapeCrackle/claude-starterstheir own version, first seen Nov 8, 2026
- juninmd/skillstheir own version, first seen Nov 8, 2026
- scoobydrew83/skillstheir own version, first seen Nov 3, 2026
- krema/agent-skillstheir own version, first seen Nov 1, 2026
- black-yt/skillstheir own version, first seen Nov 1, 2026
- Wiserax/wisecrafttheir own version, first seen Oct 25, 2026
Used with
Projects with it also use mcp-builder and code-review.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
MicrosoftSkillmcp-builder
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
Also in 3 projects that use this
GoogleSkillcode-review
Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.
Also in 3 projects that use this
Other versions24 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 24
- parcadei/Continuous-Claude★ 3.9ksame name
- parcadei/Continuous-Claude-v2★ 3.9ksame name
- parcadei/Continuous-Claude-v3★ 3.9ksame name
- codeaholicguy/ai-devkit★ 1.7ksame name
- GTMify/aigtm★ 25same name
- black-yt/skills★ 16same name
- Sathvikar01/Agent-engineering-skills★ 3same name
- juninmd/skills★ 2same name
- CassetteTapeCrackle/claude-starters★ 1same name
- hongdp/deskd★ 1same name
14 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- deep-researchSkill
- error-handlingSkill
- llm-evaluationSkill
- ml-feature-engineeringSkill
- prompt-engineerSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. 0 are common, 13 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 23 edited versions we read keep these.
13
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 37
Keep the control flow in deterministic code wherever possible.
- Distinctive: line 42
If subtask B needs even a summary of A, serialize them - parallel-then-reconcile costs more than the latency it saves.
- Distinctive: line 48
Every edge between agents gets an explicit contract, not prose.
- Distinctive: line 68
Add a critic/reviewer step for high-stakes outputs.
- Distinctive: line 101
Do not multiply agents for architecture's sake - each hop is latency, cost, and failure surface.
- Distinctive: line 102
Do not let an LLM own the control flow when code can - keep the graph inspectable.
- Distinctive: line 103
Do not pass full conversation history across a handoff.
- Distinctive: line 104
Do not retry without feedback, retry more than 2-3 times, or run without a circuit breaker.
- Distinctive: line 105
Do not skip output validation on any edge.
- Distinctive: line 106
Do not parallelize side-effectful steps.
- Distinctive: line 107
Do not ship without per-call logging - an unobservable agent system is undebuggable.
- Distinctive: line 111
Every agent's existence is justified by a named single-agent failure.
- Distinctive: line 112
Every edge has a schema-validated contract with acceptance criteria and a budget.
“Common” is measured: kept by at least 6 in 10 of the 23 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent Orchestration
Multi-agent systems fail two ways: teams split work across agents that a single capable agent handles better (paying latency, cost, and failure surface for nothing), or they wire agents together with vague handoffs and no budgets, producing loops that burn tokens until someone notices the bill. This skill designs the coordination layer - topology, contracts, budgets - so agent count is justified and every failure mode has a pre-decided response.
Operating procedure
Step 1: Gather inputs
- The end-to-end task and the acceptance criteria for its final output.
- Why one agent is insufficient - name the specific failure (context overflow, skill mismatch, needed parallelism). If the user cannot name one, the answer is one agent, and this design is over.
- Volume of context the task consumes vs the model's window; latency and cost ceilings per run.
- Which steps have side effects (writes, sends, purchases) vs are pure reads.
Step 2: Justify each agent
Split only when at least one holds:
- The task decomposes into distinct skills (research, then write, then review) whose instructions conflict in one prompt.
- Working context would exceed roughly 60-70% of the window, so subtasks must be isolated and summarized (past that point, retrieval quality inside the window degrades and cost balloons).
- Independent subtasks can genuinely run in parallel.
Each added hop adds latency, cost, and a new failure surface. Default to one agent until it demonstrably can't cope.
Step 3: Pick the topology
- Orchestrator-workers: a planner decomposes the task, routes subtasks to specialized workers, and synthesizes. Use when subtasks vary run-to-run.
- Sequential pipeline: fixed stages, each output feeds the next. Use when the stages never change - it is the cheapest and most debuggable shape.
- Router: classify the input, dispatch to one specialist. Use for heterogeneous inbound work, not decomposition.
Keep the control flow in deterministic code wherever possible; let the LLM fill in content, not decide the graph. An LLM-decided graph is uninspectable and untestable.
Step 4: Parallelize or serialize
- Parallelize only subtasks with no data dependency and no shared side effects. Reads parallelize; writes serialize.
- If subtask B needs even a summary of A, serialize them - parallel-then-reconcile costs more than the latency it saves.
- Cap fan-out at what you can review: 3-5 parallel workers per wave is the practical ceiling before synthesis quality drops and the orchestrator's merge step becomes the new bottleneck.
- Anything with side effects runs serially with validation between steps.
Step 5: Write the handoff contract
Every edge between agents gets an explicit contract, not prose. Minimum fields:
task: one-sentence objective the worker can act on without the full history.inputs: the exact artifacts passed, each summarized to budget (below).output_schema: the structure the worker must return (fields, types, length caps).done_when: acceptance criteria the orchestrator will validate against.budget: max tokens/steps/time for this subtask.
Validate every worker output against output_schema before use. An unvalidated handoff is where garbage enters the system and compounds downstream.
Step 6: Set context and cost budgets
- Pass minimal, relevant context to each worker - never the whole history. A worker's input should target well under half its window, leaving room to work.
- Summarize intermediate results before forwarding; cap summaries (a few hundred tokens is usually enough - if a worker needs more, pass a reference to the full artifact in a shared scratchpad/blackboard, not the artifact inline).
- Global run budgets, enforced by a circuit breaker: max total steps, max total tokens/cost, max wall-clock time. Pick numbers meaningfully above the p95 of a healthy run and halt hard at the ceiling.
- Retry a failed subtask at most 2-3 times, each retry carrying the validator's specific feedback; identical-input retries are wasted spend.
- Cap delegation depth at 2-3 and forbid re-dispatching a subtask already seen (track a task fingerprint) - this kills infinite delegation loops.
Step 7: Design failure handling
- Add a critic/reviewer step for high-stakes outputs; skip it for cheap, low-risk ones.
- Conflicting worker outputs: the orchestrator arbitrates with a pre-decided tie-break rule (prefer the sourced answer, or escalate to the critic) - never silently picks the first.
- Partial failure: return best-effort results with an explicit note on what failed; a silent partial success is worse than an error.
- Make every tool idempotent; agents retry, and a non-idempotent write plus a retry equals a double charge.
- Log every agent call - inputs, outputs, tokens, cost, latency - keyed by run id. This is non-negotiable: it is the only way to debug and the raw material for evals (pair with llm-evaluation).
Worked artifact: handoff contract
{
"task": "Summarize the security posture of the attached vendor questionnaire",
"inputs": [
{ "name": "questionnaire", "ref": "blackboard://run-42/vendor-doc",
"summary": "180-question SOC2-style vendor security questionnaire, completed" }
],
"output_schema": {
"risk_level": "one of: low | medium | high",
"top_findings": "array, max 5, each { finding: string<=200chars, evidence: string }",
"unanswered_questions": "array of question ids"
},
"done_when": "risk_level is set and every finding cites evidence from the document",
"budget": { "max_tokens": 8000, "max_time_s": 120, "max_retries": 2 }
}Bad contract, for contrast: "Worker 2: look at the doc and tell me if it's risky." No schema to validate, no budget to enforce, no acceptance criteria - the orchestrator cannot tell success from failure, so failure propagates.
Deliverable
Produce an orchestration design doc containing: the agent justification (or the verdict "use one agent"), the chosen topology with a diagram of edges, one handoff contract per edge, the parallel/serial decision per subtask with reasoning, the global budget table (steps, tokens, time, retry caps, depth cap), and the failure playbook (validation, arbitration rule, partial-failure behavior).
Do NOT
- Do not multiply agents for architecture's sake - each hop is latency, cost, and failure surface.
- Do not let an LLM own the control flow when code can - keep the graph inspectable.
- Do not pass full conversation history across a handoff; summarize or pass references.
- Do not retry without feedback, retry more than 2-3 times, or run without a circuit breaker.
- Do not skip output validation on any edge; one unvalidated handoff poisons everything downstream.
- Do not parallelize side-effectful steps.
- Do not ship without per-call logging - an unobservable agent system is undebuggable.
Quality bar
- Every agent's existence is justified by a named single-agent failure.
- Every edge has a schema-validated contract with acceptance criteria and a budget.
- Global circuit breaker enforces step, token, and time ceilings; delegation depth capped; duplicate dispatch forbidden.
- The run log reconstructs any failure end-to-end from run id alone.
- A dry run of the failure playbook covers: worker timeout, invalid output, conflicting outputs, and budget exhaustion.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

