What this prompt does
This prompt designs a multi-agent orchestration system where [agent_count] specialists with roles [agent_roles] collaborate to achieve [system_goal], built on [framework] with [model_provider]. It centres on an orchestrator agent that decomposes the work and delegates, a communication protocol between agents, and a shared blackboard for inter-agent knowledge.
The structure works because it confronts the two places naive multi-agent setups break: coordination and cost. A task dependency graph defines execution order and surfaces what can run in parallel, while a quality-gate validation agent reviews outputs before delivery. Crucially, it allocates a [token_budget] across agents and adds end-to-end trace logging, so you can see exactly which agent did what and why a chain failed instead of staring at an opaque pile of calls.
The communication protocol and shared blackboard are what let independent agents actually collaborate rather than talk past each other. A defined message format and routing keeps delegation predictable, the blackboard gives every specialist a common place to read and write intermediate knowledge, and a fallback strategy means one agent failing does not silently sink the whole run. Together these turn a fragile chain of model calls into a system you can reason about and recover.
When to use it
- You have a task that genuinely splits into specialist roles like
[agent_roles]rather than one agent doing everything. - You need an orchestrator to decompose and delegate work, not a flat pipeline.
- You want parallel execution of independent sub-tasks to cut latency.
- You need conflict resolution when two agents produce contradictory outputs.
- You are worried about runaway cost and want a
[token_budget]enforced across the whole chain. - You need trace logging to debug why a multi-step agent run went wrong.
Example output
Expect an orchestration design: a sequence diagram showing the orchestrator delegating to specialists, the message format and routing protocol, the blackboard memory schema, a task dependency graph marking parallelizable steps, and an example run on a real task. It typically includes the [token_budget] allocation strategy and the trace-logging format for debugging.
Pro tips
- Keep
[agent_count]as low as the goal allows. More agents means more coordination overhead and more places for the chain to break. - Define
[agent_roles]with clear, non-overlapping responsibilities — overlapping roles cause the conflicts the resolution step then has to clean up. - Set
[token_budget]deliberately and allocate the largest share to the agents doing the heaviest reasoning. - Make
[system_goal]concrete and outcome-shaped; a fuzzy goal produces a fuzzy decomposition from the orchestrator. - Lean on the quality-gate agent — a validation pass before delivery catches contradictions the individual agents miss.
- Treat trace logging as essential, not optional; without it, debugging a failed multi-agent run is guesswork.
- Define a clear fallback for each agent so a single specialist failing degrades gracefully instead of collapsing the whole chain.
- Keep the blackboard schema tight; an unstructured shared memory becomes a dumping ground that agents misread.
