Write · Create · Writing & Content

Write the orchestration-pattern spec for my multi-agent workload

You get a complete, section-by-section orchestration-pattern spec for one named multi-agent pattern, with every declared agent role scoped and bounded, every published contraindication for that pattern answered in writing, and every pattern claim traced to a cited source.

You receive: One structured JSON spec document. Its top-level fields are chosenPattern (exactly one of the five published pattern names: sequential, concurrent, group-chat, handoff, magentic), azureAliases, crossFrameworkEquivalence (an object with anthropicEquivalent and basis, where basis is exactly one of azure-states-it or no-equivalent-in-cited-sources), complexityJustification, sections, agentRoles, conversationControlJustification (required only for group-chat above 3 agents), hitlGates, contraindicationsAddressed, implementationConsiderations (with the six required keys contextAndState, reliability, security, costOptimization, observabilityAndTesting, humanParticipation), and patternClaims (each carrying a citation whose source is one of azure-orchestration-patterns or anthropic-building-effective-agents). Only three cross-framework mappings are accepted, verbatim: sequential maps to "prompt chaining", concurrent maps to "parallelization", and group-chat with the maker-checker sub-type maps to "evaluator-optimizer". For handoff, for magentic, and for group-chat with the open-discussion sub-type, anthropicEquivalent must be the empty string and basis must be "no-equivalent-in-cited-sources": in particular a spec that asserts handoff equals Anthropic "routing" is rejected (the tokens refused in anthropicEquivalent for handoff, verbatim: routing, route, router, dispatch-classify, classify-then-dispatch), and a handoff spec must instead contain the section handoffVsDeterministicRoutingDistinction.

Part of Ship MVP

What's verified: WHAT IS CHECKED, and only this. The spec is checked as a SHELL, mechanically, against your frozen intake values. Thirteen rules, all of them pure functions of your submitted document and your intake answers. 1) The pattern you name must be exactly the one you selected at intake, and it must be one of these five published names, verbatim: sequential, concurrent, group-chat, handoff, magentic. No other name is accepted. 2) Every required section for that pattern must be present and must meet your own minimum word count (default 40). The required sections are published, verbatim. Common to all five patterns: problemStatement, coordinationModel, routingRule, agentRoster, stateAndContextHandoff, failureHandling, terminationCriteria. Additional per pattern: sequential adds stageOrder, outputValidationBetweenStages; concurrent adds aggregationStrategy, conflictResolution, sharedStateIsolation; group-chat adds chatManagerTurnPolicy, completionTest, iterationCap, checkerAcceptanceCriteria; handoff adds handoffTriggers, loopPrevention, humanEscalationTarget, handoffVsDeterministicRoutingDistinction; magentic adds taskLedgerFields, replanTriggers, stallDetection, planReviewGate. 3) Exactly as many agent roles as you declared, each with a scope of 3 or more words and a stop condition of 3 or more words, and no duplicate role names. 4) If you chose group-chat with more than 3 agents, a written conversationControlJustification of 20 or more words is required. The source advises 3 or fewer agents for control: more is allowed, unexplained is not. 5) Every published contraindication (the "when to avoid" list) for your chosen pattern must be addressed, each in 15 or more words. The enforced contraindication ids, verbatim: sequential: embarrassingly-parallel, few-stages-single-agent-suffices, early-stage-failure-propagates, agents-must-collaborate-not-hand-off, workflow-needs-backtracking-or-iteration, needs-dynamic-routing-on-intermediate-results. concurrent: agents-need-cumulative-context-in-sequence, requires-deterministic-reproducible-order, resource-or-quota-constraints, cannot-coordinate-shared-state-changes, no-conflict-resolution-strategy, aggregation-logic-too-complex. group-chat: basic-delegation-or-linear-pipeline-suffices, real-time-latency-makes-discussion-overhead-unacceptable, hierarchical-or-deterministic-decision-making-fits-better, no-objective-completion-test, conversation-loop-control-with-many-agents. handoff: right-agent-identifiable-from-initial-input, routing-is-deterministic-and-rule-based, suboptimal-routing-harms-user-experience, operations-should-run-concurrently, infinite-handoff-loop-or-excessive-bouncing. magentic: solution-path-is-deterministic, no-requirement-to-produce-a-ledger, low-complexity-simpler-pattern-suffices, work-is-time-sensitive, frequent-stalls-or-infinite-loops-without-resolution. 6) At least your declared minimum number of pattern claims (default 3), each stated in 8 or more words and carrying a citation whose source is one of the sources you allowed, with a section title of 3 or more characters. The only accepted source values, verbatim: azure-orchestration-patterns, anthropic-building-effective-agents. 7) At least one of the primary source's own also-known-as names for your pattern must be listed in azureAliases. The enforced alias tokens, verbatim: sequential: pipeline, prompt chaining, linear delegation. concurrent: parallel, fan-out/fan-in, scatter-gather, map-reduce. group-chat: roundtable, collaborative, multiagent debate, council, maker-checker, generator-verifier, critic loop, reflection loop. handoff: routing, triage, transfer, dispatch, delegation. magentic: dynamic orchestration, task-ledger-based orchestration, adaptive planning. 8) Cross-framework equivalence is enforced ONLY where the cited sources actually support a mapping. There are exactly three supported mappings, published verbatim: sequential maps to "prompt chaining" (the primary source names prompt chaining as a sequential alias); concurrent maps to "parallelization" (the primary source names parallel, the secondary source names parallelization for the same shape); group-chat with the maker-checker sub-type maps to "evaluator-optimizer" (the primary source states this equivalence outright). In those three cases crossFrameworkEquivalence.basis must be exactly "azure-states-it". For every other case there is NO accepted cross-framework name and the field must be explicitly empty. Those cases, published verbatim: handoff; magentic; group-chat with the open-discussion sub-type. In each, crossFrameworkEquivalence.anthropicEquivalent must be the empty string and crossFrameworkEquivalence.basis must be exactly "no-equivalent-in-cited-sources". The only two accepted basis values, verbatim: azure-states-it, no-equivalent-in-cited-sources. This is deliberate: the secondary source has no counterpart for group chat, and none for magentic (its nearest analogue, the autonomous agents section, is equated to magentic by neither source), so requiring a name there would reward you for inventing one. 9) Handoff is NOT accepted as equal to the secondary source's "routing". A handoff spec asserting that equivalence FAILS. The primary source does list "routing" among handoff's informal aliases (so "routing" stays legal in azureAliases under rule 7), but its own when-to-avoid guidance sends you to deterministic routing or a simpler dispatcher INSTEAD of handoff, which makes them different shapes, not synonyms. The tokens rejected in the anthropicEquivalent field for handoff, verbatim: routing, route, router, dispatch-classify, classify-then-dispatch. In exchange, a handoff spec must contain the section handoffVsDeterministicRoutingDistinction, 20 or more words. 10) A simpler level must be named and ruled out in 20 or more words. The accepted values, verbatim: direct-model-call, single-agent-with-tools. 11) All six implementation-consideration blocks present, each 15 or more words. The required keys, verbatim: contextAndState, reliability, security, costOptimization, observabilityAndTesting, humanParticipation. The source scopes these considerations to ANY of the five patterns, not to one, so this key set is identical whichever pattern you choose. 12) If you answered yes to agents reading data some users may not see, the security block must contain both of these literals: "least privilege" and "security trimming". 13) Your declared human involvement must match the spec's gates. If you chose mandatory-gate, at least one blocking gate is required and the humanParticipation text must mention persistence. If you chose optional-observer, gates must be present and non-blocking, and each still needs a named point and an accepted onResponse value. If you chose none, the gate list must be empty and humanParticipation must still explain the position in 15 or more words. The accepted onResponse values, verbatim: approve-advance, feedback-loop-back. WHAT IS NOT CHECKED, plainly. Whether you picked the RIGHT pattern for your workload is a judgment call and it is NOT verified. Nothing here reads your workload summary and rules on pattern fit: a spec that names magentic for a fully deterministic pipeline can pass every rule, because the check is that you ANSWERED the "solution-path-is-deterministic" contraindication, not that your answer is correct or convincing. Citation FIDELITY is not verified either. Only two things about a citation settle: that its source is one you allowed, and that a section title is present. Whether the cited section actually says what your claim says it says, whether a quoted line is accurate, and whether the citation is the right one for that claim are all unverified. Treat the citation check as a shape check, never as a fact check. Also not checked: whether your agent scopes are genuinely non-overlapping, whether your stop conditions actually terminate, whether your aggregation or conflict-resolution strategy would work, whether the mapping you assert in the three supported cases is used correctly in context (only the exact name and basis are compared), and whether the word-count floors you set produce depth rather than padding. Word counts are a floor on effort, not a measure of quality. Two further limits. The five-pattern taxonomy is the primary source's, not a universal one; other published taxonomies partition the same territory differently, and this contract enforces the primary source's names with only the three source-supported cross-framework mappings folded in, rather than inventing a third naming or forcing mappings the sources do not make. And the sources give guidance, not law: both texts say to combine patterns across stages of one workload, so a single-pattern spec is a deliberate simplification of what the sources actually recommend, not their full position. If your workload needs sequential intake feeding concurrent analysis, that is two specs, not one.

Opens soon

Cost20 credits

ProtectionHeld until verified delivery

This play is verified and ready. It opens soon, once sign-in and payments are live.

Example

A sample of what this play produces. Your result is generated for your inputs.

Chosen Pattern

sequential

Azure Aliases

pipeline
prompt chaining
linear delegation

Cross Framework Equivalence

Anthropic Equivalentprompt chaining

Basisazure-states-it

Complexity Justification

Simpler Level Consideredsingle-agent-with-tools

Why InsufficientA single agent with tools could in principle read the contract, draft the artifact, and call the judge, but folding all three into one agent would erase the separately auditable stop conditions this workload depends on, and would let a contract misread flow straight into a draft with no gate between reading and writing.

Sections

Problem StatementSTUD.com authors one buyer facing sample deliverable for every play in its catalog, so each play page can show a real example that would settle against that play's own judge. Doing this by hand across the whole catalog is slow and error prone, so the workload needs a repeatable pipeline that reads each play's frozen contract, drafts a conforming artifact, and proves it settles before it ships to the buyer facing page.

Coordination ModelCoordination is a one directional pipeline. A single orchestrator invokes four agents in a fixed order for each play, passing one typed payload from each stage to the next. No agent talks to any other agent directly, and no shared mutable state is edited concurrently, so the only coordination primitive is the ordered handoff of the prior stage's output as the next stage's sole input.

Routing RuleThere is no content based routing inside a single play. Every play flows through the same four stages in the same order regardless of its domain or difficulty. The only branch is the judge's binary result at the verification stage, which either advances the run to the writer or loops the draft back to the same drafter, and it never dispatches the work to a different agent based on intermediate content.

Agent RosterThe pipeline defines four agents. The contract reader turns a play's seed row, machine interface, and judge task into a frozen requirements bundle. The spec drafter authors the JSON deliverable against that bundle and the buyer facts. The judge gate submits the draft to the platform owned judge and reports the result. The result writer persists the accepted deliverable and its verdict into the wave results manifest.

State And Context HandoffState moves forward only, as explicit typed payloads. The contract reader emits the frozen requirements bundle, which is the single source of truth for the run. The drafter attaches its draft to that bundle. The judge gate attaches the verdict, including the exact failing checks when a submission is rejected. Each stage reads only what the prior stage produced, so there is no hidden global context to drift out of sync.

Failure HandlingEach stage fails closed. If the contract reader cannot capture a required field or enum value, the run halts before any draft is written. If the judge gate reports not accepted, the exact failing checks are handed back to the drafter for a bounded revision, capped at five attempts. If the cap is reached without acceptance, the run records the best attempt and the failing checks rather than shipping a sample the judge has not accepted.

Termination CriteriaA run terminates in exactly one of two states. It succeeds when the judge returns accepted true, at which point the result writer persists one result file and the pipeline stops. It stops without success when the drafter has exhausted its five revision attempts, in which case the run records the best draft alongside the exact failing checks so a founder can escalate. No run continues past these two outcomes.

Stage OrderThe stages run strictly in this order: first the contract reader, then the spec drafter, then the judge gate, then the result writer. The order reflects hard data dependencies, since drafting cannot begin without the frozen requirements bundle and the judge cannot run without a draft. The only permitted repetition is a bounded revise loop between the drafter and the judge gate, which never reorders the surrounding stages.

Output Validation Between StagesValidation sits between drafting and completion, not only at the end. The contract reader's bundle is schema checked before the drafter runs, so a malformed requirements set never reaches drafting. The drafter's output is validated by the platform owned judge, which returns accepted only when every published check passes. The writer runs only after that accepted verdict, so no unaccepted artifact is ever persisted to the wave results manifest.

Agent Roles

Name	Scope	Stop Condition
Contract Reader	Read the play seed row, machine interface, and judge task, then emit a frozen requirements bundle	Stops when every required field, enum value, and word floor is captured in the bundle
Spec Drafter	Draft the JSON deliverable strictly against the frozen requirements bundle and the buyer facts	Stops when a complete draft covering every required field is produced
Judge Gate	Submit the draft to the platform owned judge and return accepted or the exact failing checks	Stops when the judge returns accepted true, or after five submission attempts
Result Writer	Write the accepted deliverable and its verdict into the wave results manifest	Stops once one result file is written for this play

Contraindications Addressed

Contraindication	Response
embarrassingly-parallel	The four stages have hard data dependencies: drafting cannot begin until the contract is read, and the judge cannot run until a draft exists, so within one play the work is not embarrassingly parallel even though separate plays are authored concurrently by the outer run.
few-stages-single-agent-suffices	Although only four stages exist, each demands a distinct competence: reading a locked contract, authoring conforming data, running an external verifier, and persisting results, so collapsing them into one agent would blur the separately auditable stop conditions this workload requires.
early-stage-failure-propagates	A misread contract would poison every later stage, so the pipeline inserts an explicit gate: the draft is not accepted on the drafter's word but only when the platform owned judge returns accepted, which contains an early stage error rather than letting it propagate silently downstream.
agents-must-collaborate-not-hand-off	The stages do not negotiate or deliberate; each consumes the prior stage's typed output and produces the next, which is a clean handoff rather than collaboration, so the sequential pipeline fits and a group discussion pattern would add coordination overhead with no benefit here.
workflow-needs-backtracking-or-iteration	Iteration is bounded and local, not global: only the drafter and judge gate form a revise loop, resubmitting a corrected draft up to five times against the same frozen contract, so the pipeline needs no general cross stage backtracking and the linear stage order holds for every accepted run.
needs-dynamic-routing-on-intermediate-results	Nothing in this workload routes on intermediate content: the stage order is fixed regardless of which play is authored, and the only branch is the judge's binary accepted or not accepted result, which loops back to the same drafter rather than dispatching to a different agent, so no dynamic routing is needed.

Implementation Considerations

Context And StateEach stage receives only the prior stage's typed payload, so context is passed explicitly rather than shared globally, which keeps every run reproducible and lets a rejected draft carry its exact failing checks forward without polluting later state.

ReliabilityReliability rests on the judge gate: a draft is accepted only when every published check passes, and the bounded five attempt revise loop prevents a sample the judge has not accepted from ever reaching the writer or the buyer facing play page.

SecurityAgents operate only inside STUD's own repository and judge with least privilege read access, and they touch no end user data, so no untrusted content crosses a user trust boundary during a run of this authoring pipeline.

Cost OptimizationCost is controlled by capping the revise loop at five judge submissions per play and by running the cheapest capable model for drafting, reserving higher effort only for plays whose contracts prove hardest to satisfy.

Observability And TestingEvery run emits the frozen requirements bundle, the draft, and the judge verdict, so each accepted sample is traceable to the exact checks it passed, and a failed run records the best attempt with its failing checks for later escalation.

Human ParticipationThe pipeline runs without an in run human gate, since the platform owned judge is the automated acceptance gate. A founder review of accepted samples happens as a separate downstream step before any merge to production, outside the scope of this orchestration.

Pattern Claims

ClaimSequential orchestration chains agents so each one's output becomes the next one's input.

Citation

Sourceazure-orchestration-patterns

Section TitleSequential orchestration

ClaimPrompt chaining decomposes a task into a fixed series of steps, each handling the previous step's output.

Citation

Sourceanthropic-building-effective-agents

Section TitleWorkflow: Prompt chaining

ClaimAdding a programmatic check between steps trades a little latency for higher accuracy on decomposable tasks.

Citation

Sourceanthropic-building-effective-agents

Section TitleWorkflow: Prompt chaining

ClaimSequential pipelines fit workloads whose stages have a clear, deterministic order of dependencies.

Citation

Sourceazure-orchestration-patterns

Section TitleWhen to use sequential orchestration

Get early access to STUD the day it goes live.