How to Build a Multi-Agent Workflow with GPT-6 Astra

Multi-agent systems are useful when one complex task contains independent workstreams that can run in parallel. They are wasteful when every step depends on the last. GPT-6 Astra’s Responses API multi-agent feature lets a root agent spawn, message, and wait for subagents, then synthesize their findings.

At the verification date, OpenAI documents Responses multi-agent as a beta feature. The JavaScript and Python quickstarts use the beta Responses SDK; raw HTTP and WebSocket integrations send the OpenAI-Beta: responses_multi_agent=v1 header. Item schemas may change, so isolate beta handling behind an adapter.

Pick work that actually decomposes

Strong candidates include exploring separate codebase areas, comparing documents, researching independent hypotheses, or implementing isolated test suites. Weak candidates include a single ordered calculation, a small task, a shared file that every worker must edit, or one slow external call that dominates runtime.

Subagents can reduce wall-clock time and context interference, but they increase token use. Optimize successful-task latency and quality, not agent count.

Root and subagent responsibilities

Set multi_agent.enabled so the root becomes eligible to spawn a tree of subagents. Subagents share the request’s model and available tools. The root should:

• define the outcome and decomposition criteria;
• assign bounded, non-overlapping tasks;
• pass the minimum sufficient context;
• resolve conflicts and gaps;
• synthesize one accountable final answer.

A subagent brief should state scope, expected output, evidence requirements, constraints, and completion condition. “Research competitors” is vague. “Compare public pricing and export features for these four named products, cite primary pages, and flag unknowns” is testable.

Control shared mutable state

Parallel agents should not edit the same record or file without coordination. Prefer read-only exploration followed by a single root-owned commit. For code, divide by module and run an integration pass. For business systems, let subagents propose actions while the root or an application transaction performs the write.

In a creative pipeline, separate agents might review script continuity, character consistency, and audio requirements, with the root producing one production brief for Elser AI. They should not independently overwrite the same storyboard.

Budget the tree

Set application limits for depth, concurrent agents, total tokens, tool calls, elapsed time, and retries. The official guidance notes that subagents can increase token usage. A bounded tree also prevents recursive delegation from becoming an accidental denial of service.

Give the root an explicit instruction about when delegation is allowed. If the workflow needs predictable orchestration, implement the graph in your application instead of asking the model to invent it.

Synthesis is a separate task

Do not concatenate subagent outputs. Ask the root to compare claims, check citations, identify disagreement, and state which evidence wins. Preserve provenance through source IDs or structured result fields.

A synthesis contract can require:

• findings shared by all workstreams;
• disagreements and their causes;
• missing evidence;
• recommended action and confidence;
• which subagent/source supports each consequential claim.

If two agents depend on the same flawed source, apparent consensus is not independent confirmation.

Security and approvals

Subagents inherit available tools, so keep the catalog narrow. Server-side authorization applies to every call regardless of which agent requested it. Require approval for consequential actions and identify the actual action, not merely the subagent name.

Treat messages between agents as untrusted model content. Validate structured results and avoid passing secrets unless the task requires them. A root agent cannot safely “supervise” permissions that the application fails to enforce.

Evaluate the workflow

Compare multi-agent against a single-agent baseline on the same test set. Measure answer quality, coverage, latency, tokens, tool calls, duplicate work, conflict rate, and integration failures. Inject failures: one slow subagent, one wrong finding, one tool outage, and one worker that never returns.

Adopt multi-agent only when the gain justifies orchestration complexity. A smaller agent tree with clearer briefs often outperforms a large committee.

Reference pattern: parallel research, serial decision

Consider a migration assessment. The root creates three bounded workstreams: one agent inventories API usage, one reviews security implications, and one estimates operational cost. All three are read-only and return a common schema: findings, evidence, uncertainty, and recommended actions. The root waits, identifies conflicts, and writes one plan. Only after human approval does application code create tickets.

This pattern works because exploration is independent while the decision and mutation remain serial. It also gives the root a chance to notice duplicated evidence. If every agent cites the same outdated page, the synthesis should flag the shared dependency instead of counting three votes.

Set a timeout policy before execution. The root should be able to finish with two of three reports while explicitly naming the missing workstream, or cancel the run when that stream is mandatory. Avoid endless “wait” cycles. Store subagent IDs and terminal states so an operator can diagnose the slow branch without reading the entire transcript.

For regulated decisions, require the root to quote structured evidence IDs rather than free-form recollection. The final action should be traceable to source, agent result, root synthesis, and human approval.

FAQ

Is GPT-6 Astra multi-agent generally available?

The official guide labels the Responses multi-agent feature beta as of September 7, 2026. Check the model page and guide before deployment.

Do subagents use different models?

The documented feature says subagents share the request’s model and available tools.

Is multi-agent always faster?

No. Coordination and synthesis add overhead, and one slow dependency may dominate the run.

When should orchestration stay in application code?

When the graph must be deterministic, steps are ordered, writes share mutable state, or compliance requires explicit transitions.

Conclusion

A good GPT-6 Astra multi-agent workflow is a controlled decomposition system: independent briefs, bounded contexts, minimal tools, no uncontrolled shared writes, and rigorous synthesis. Start with a single-agent baseline, add parallelism only where work truly separates, and treat beta schemas and higher token consumption as operational constraints.