Verified against LangGraph · 2026-07-27
Design a planner-executor split so one agent doesn't do everything badly
A system-design prompt for architecting a multi-agent system before any orchestration code exists — choosing between hierarchical, sequential, and peer-negotiation patterns, and defining a named handoff schema at every boundary instead of letting agents pass free-form context between each other.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are architecting a multi-agent system for the goal below, deciding how to split the work across a planner and one or more specialist executor agents before any orchestration code gets written. Your job is to design the role split and handoff contract, not to write the goal-completion logic each agent will run internally. GOAL AND CONSTRAINTS Given a customer's renewal request, gather usage data, check contract terms, and draft a renewal proposal with pricing No agent may send anything to the customer directly; a human sales rep approves and sends the final proposal CANDIDATE EXECUTOR ROLES usage-analyst (queries product usage data), contract-reader (extracts terms from the signed contract PDF), pricing-agent (applies the discount matrix), proposal-writer (drafts the final document) ARCHITECTURE PATTERNS TO WEIGH 1. Hierarchical (planner decomposes, assigns each subtask to one executor, collects results) — clear accountability, but the planner becomes a bottleneck and a single point of failure if it plans badly. 2. Sequential pipeline (fixed order, each agent's output is the next agent's input) — simple to reason about, but brittle if a later stage needs to send work back to an earlier one. 3. Peer negotiation (agents propose and critique each other's plans before executing) — catches planning errors early, at the cost of more LLM calls and a real risk of the agents converging on agreement without actually resolving the disagreement. STATE AND HANDOFF DESIGN For each boundary between agents, specify exactly what data crosses it — not "the context" or "everything so far," but a named, minimal payload. State what each executor needs to start and what it must return in a fixed shape the next stage can consume without re-parsing free text to figure out what happened. usage-analyst must hand pricing-agent a specific number (monthly active seats, feature usage %) not a narrative summary of usage trends FAILURE MODES TO DESIGN AGAINST - What happens when one executor fails or returns a low-confidence result — does the planner retry it, route to a different executor, or escalate to a human? Name the rule per role, don't leave it to be decided at runtime. - What happens when two executors would both plausibly handle the same subtask — is there a tie-breaking rule, or does the planner own that decision every time? - What stops an executor from silently expanding its own scope into another executor's territory because the boundary between them was fuzzy in the design, not just the runtime prompt? BUDGET Under 12 total LLM calls per renewal, completing within 3 minutes — state how many total LLM calls this architecture requires for a typical run, and whether that fits. OUTPUT FORMAT 1. The chosen pattern and a diagram-in-words of the agent roles and handoffs. 2. The handoff contract for every boundary, as a named schema. 3. The failure-handling rule per role. 4. The estimated LLM-call count per typical run, and whether it fits the stated budget.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Specifying a named, minimal handoff payload at each boundary — rather than the common shortcut of passing the entire conversation history to the next agent — matters for two concrete reasons. First, every additional token another agent has to read is money and latency, and an executor drowning in irrelevant upstream reasoning is more likely to pick up on something it shouldn't and act on it out of context. Second, and more subtly, an agent that receives free-form prior context has to reparse it to figure out what actually happened, and that reparsing step is itself a place a model can misread what a previous agent concluded — a named schema field like discount_percent: 12 can't be misread the way a paragraph summarizing a pricing decision can. Requiring a failure-handling rule per role at design time, instead of leaving it to be decided by whichever agent happens to be running the show when something goes wrong, addresses a specific reliability problem with LLM-orchestrated systems: an LLM planner improvising how to handle a failed executor call will make a plausible-sounding decision every time, but not the same plausible-sounding decision every time — one run it retries, the next it silently proceeds without the missing data, the run after that it escalates. That inconsistency is invisible in a demo and expensive in production, because it means the system's behavior under failure is genuinely non-deterministic in a way its behavior under success usually isn't. Forcing an explicit LLM-call budget comparison is what keeps the architecture pattern choice honest. Peer negotiation, where agents propose and critique each other's plans, sounds obviously more robust than a fixed pipeline — until the call count is written down next to the actual latency and cost target, at which point a pattern that multiplies the number of model calls per run by three or four either clearly earns its cost against a specific failure it prevents, or it doesn't, and the prompt won't let that tradeoff stay implicit.
Verified against
LangGraph 0.4 · 2026-07-27
CrewAI 0.98 · 2026-07-27
Changelog
- 2026-07-27 — Initial publish, verified against LangGraph 0.4 multi-agent graphs and CrewAI 0.98 hierarchical crews.
Building this for real?
This is a free starting point. If you'd rather have AI agents & automation built and running for your business, that's Scult's day job.
EXPLORE AI AGENTS & AUTOMATION
