How agent orchestration works

A request follows the same path from the user to a domain agent and back.

Authentication and authorisation happen at the gateway, against the user’s identity and tenant. They do not use the agent contract. The contract decides where a request goes, not whether it is allowed.

The root orchestrator is the only component users interact with directly. It presents a single interface and forwards each request to the domain agent that handles it; users never address an agent directly.

The orchestrator:

The orchestrator does not enforce an agent’s tool permissions, because those are not part of the contract. Each agent’s permissions are governed by its own execution gateway virtual key. The orchestrator also does not inspect agent output for correctness. It routes and relays; it does not police what each agent is allowed to do.

The agent registry holds each agent’s contract. Each agent publishes a contract describing its identity, reachability, and skills, and the seed process upserts that contract into the registry. When a user runs an agent, the orchestrator looks up that agent’s contract and routes to the URL the contract advertises.

The user selects which agent to use; the orchestrator does not infer it from the request. Because routing depends on the address an agent advertises, an accurate contract matters. A contract that advertises an unreachable URL causes routing failures that surface only at request time. For how contracts are written, published, and seeded, see Understanding agent registration. For the field-by-field schema, see Agent contract specification.

The orchestrator validates agent responses narrowly. It checks that each response is a well-formed A2A response. It does not check the content of a response, such as whether a response that should carry structured data actually does. It does not cross-check an agent’s tool calls against the contract, because the contract declares no tools.

This keeps the orchestrator decoupled from agent internals. Agents can change how they work, and which tools they use, without the orchestrator needing to know. Each agent and its developers own the correctness of its output.

The orchestrator and domain agents communicate using A2A, the open standard the agent contract is built on. Domain agents receive requests from the orchestrator, do their work, and return results. They do not communicate with users directly, and a run involves a single agent, so agents do not communicate with each other.

Standardising on A2A is what makes the platform extensible. Any A2A-compliant agent is discovered and addressed the same way, so teams across Storyteq can build and deploy new agents without changing orchestrator code. A new agent becomes routable as soon as its contract is seeded into the registry.

The orchestrator records each run as it happens. User messages and agent responses are stored as the conversation progresses, including text, files, and structured data parts.

This history is a record of the conversation, not a workflow checkpoint. A run belongs to one agent, and a message that fails is recorded as failed; the orchestrator does not retry it or resume it from a partial step.

Multi-agent workflows, where the platform chains agents, passes data between them, and retries individual steps, are not part of the current model. They are planned for a future release.