Multi-agent systems

By the end of this page you will have deployed a multi-agent system (MAS) as a production deployment and know how its member agents are exposed.

Prerequisites

Admin role.
A multi-agent system with a PRODUCTION version — see Publish.
Every member agent published to production.

What a MAS deployment is

A multi-agent system coordinates several agents to handle a request. When you deploy one, you get a single endpoint: the system’s router receives each request and directs it to the right member agent. The members are deployed automatically as part of the system, and they’re managed as part of it — you add or remove them by publishing a new version of the system, not by editing the deployment.

This makes a MAS deployment an Agent API with one entry point, regardless of how many agents are inside. Each member also keeps its own agent endpoints on the same deployment, so you can call a specialist directly when you need to — see the Agents tab.

Build the system itself in the MAS Systems section.

Deploying a system

On the Deployments page, click Deploy and choose MAS System. Pick the system to deploy — only systems with a PRODUCTION version are listed. The picker shows each system’s pattern and how many member agents it has.

Deploy MAS dialog showing a system with its pattern type, member count, deployment target, and API key options

Configure the deployment

Choose a new deployment (enter an app slug and production domain) or add the system to an existing deployment. Set whether API keys are enabled and the rate limit (requests per minute). The dialog previews the system’s endpoint URL.

Review and deploy

Confirm the members — listed as auto-deployed — and the credit summary, then deploy. If you enable API keys, a key is shown once on the success screen; copy it.

The Systems tab

Open the deployment and select Systems to see the deployed system: its pattern type, its member agents, and its rate limit.

Systems tab showing a deployed multi-agent system with its pattern type and member agents

The routing pattern is set when the system is built — the Conversation Router, which routes each request to the best specialist agent. See How routing works for how that decision is made.

You can also switch the system’s version here, which is how you roll out a newly published configuration.

ℹ️

Member agents are managed as part of the system, not individually. To change a member, update the system in the builder and publish a new version.

Calling a system

A deployed system is called at its own endpoint under the deployment’s base URL, authenticated with an API key. Requests go to the router, which handles delegation to members internally.

Common issues

The system isn’t listed to deploy — it needs a PRODUCTION version. Publish it in the builder first.
“Cannot deploy system: member agent … has no published version.” — every member needs a published version, because they’re deployed with the system. Publish the named agents and retry.
A member isn’t responding — check the Agents tab: the member is deployed alongside the system and has its own endpoints and test console there.
The deployed system ignores a change you made — the deployment runs the system’s pinned version. Publish the system, then switch the version on this tab.