Skip to main content
A Space is a supervisor agent with a roster of member agents. The end user talks to the Space; on each turn the supervisor model decides whether to answer itself or consult one or more members, then writes the final reply from their results. Spaces exist so an organization can present one conversation over several specialized agents without merging them into one.

​
How a Space routes a conversation

A Space is created and configured in the admin dashboard under Spaces: you name it, write its persona, and select the member agents. The platform also creates a private personal Space for each member when they join an organization; it supervises the organization’s public agents and is that member’s own entry point to them. Each member’s routing description is what the supervisor reads to decide who handles what; for a member built from source, that text is description on LuaAgent, which lua push agent updates, and a summary of the member’s persona stands in when it is not set. Routing is model-driven. The supervisor sees each member’s name and routing description, the Space persona, the request, and the conversation so far. It routes on capability, honors an explicit “ask the research analyst” request for a listed member unless another member’s description clearly fits better, makes one delegation per consultation (the same member twice is two calls), does not fall back to a mismatched member when the right one fails, asks a clarifying question when a request could belong to more than one member, and answers directly for general conversation. It never reports a consultation it did not make. There is no rule syntax, no guaranteed sequence, and no guarantee that the model chooses the route you expected; you shape routing with descriptions and the Space persona, and you test it. A consulted member runs as itself: its own persona, model, tools, processors, governance rules, and connections. It does not receive the full Space thread. It receives the delegation instruction and a token-budgeted brief of the conversation (recent messages, the current request verbatim, attachment handles, and compressed memory when the Space thread keeps it), and it returns plain text. A fact that appears only far back in a long conversation may not fit the brief; repeat it in the request. A member keeps its own tools while delegated but not the Space’s end-user-facing tools (cards, scheduling, inbox questions, memory, and workflow tools); the Space applies those to the returned text. The Space learns which tools a member called, by name, count, and whether they failed, never their output. Each delegation is an attempt with an outcome: succeeded, failed, failed with an empty result, or rejected before the member ran (by governance, a preprocessor, a failed policy check, billing, or the per-turn budget). The platform caps delegation attempts per turn, 12 by default, and stops with Space delegation limit reached for this turn (12). Space configuration lives in the admin dashboard only: the CLI has no Space manifest, version, diff, promote, or local test. A Space has no agent versions, so there is no rollback for the Space itself; each member keeps its own versions and rollback. A Space has an ID of the form space_…, shown as the last segment of its dashboard URL, and chat endpoints and clients that accept an agentId accept it. Connections follow their owner. Attaching a connection to a Space does not give members access to it. When a member is consulted, its Unified.to connections are filtered to the ones the end user in the conversation may use (their own, shared with the organization, or designated by it); any other MCP server a member carries is agent-level configuration and serves everyone who reaches that member. Keep personal accounts on private agents, and verify direct chat, Space delegation, jobs, and triggers separately before production.

​
Spaces and one agent with more skills

The alternative to a Space is one agent with more skills. A skill is chosen by the model from tool descriptions inside one persona, one model, and one set of processors; it is cheaper, and it is versioned and rolled back as part of the agent. A Space is the right shape when members must differ in persona or model, when a member must also be usable on its own, or when a member’s tools and connections must stay isolated from the others. A Space does not sequence work: for ordered steps, retries, or approvals, use a workflow.

​
When to use it

  • Several agents already exist and end users should not have to pick one.
  • Members need different personas or models, or carry connections that must not be shared.
  • Don’t use a Space for deterministic routing, ordered steps, or long-running work; use a workflow.
  • Don’t split one agent into members to organize code; use skills.

​
Limits

​
Next steps

About agents

Build the member agents a Space consults.

About workflows

Ordered, durable steps with approvals.

About models

Model pins, resolvers, and explicit overrides.

For operators

What you change in the admin dashboard and what needs an engineer.