How Mission Control works

Mission Control sits between your applications and their AI providers and tools. It gives teams a shared place to control access, set limits, inspect requests, and evaluate agent behavior. You can keep your application in your own code or build an Agent in the Console.

Follow one request

Suppose a support application needs a model and a customer-record lookup tool:

1. An administrator registers the provider and Connector in the Organization catalog.
2. The administrator allows the Support Team to use the support virtual model and the lookup tool.
3. A developer creates a virtual key for a user or service account in that Team, choosing its permitted operations and resources.
4. The application sends a request to the gateway. Mission Control checks the credential, current access, applicable rules and limits before dispatching work.
5. The gateway calls the configured provider or tool. It records the decision, outcome and available usage; trace observations describe the work in more detail.

support is an example model name. Your application uses the virtual model IDs and tool schemas discovered from your own deployment.

The parts you work with

Part	Responsibility	Learn more
Console	Sign-in, Team administration, keys, Agents, Chat, observation and evaluation	User guide
Inference gateway	Model requests, MCP tool calls and published Agent invocations	Models and tools
Private control listener	Management APIs, service coordination and operational probes	API boundaries
Managed Agent runtime	Executes saved Agent definitions through the governed gateways	Agents and deployments
Telemetry services	Receive standard OTLP spans and serve retained observations	Requests, Traces and Sessions

PostgreSQL stores control state, decisions and financial records. The Collector and ClickHouse provide the trace pipeline. A missing trace does not mean a request was not admitted or charged. Operators can follow the supported deployment topology.

Understand the boundaries

Human permissions determine what someone can manage or inspect. Virtual-key policy determines what an application can invoke. Becoming a Team administrator does not turn a provider credential into a Mission Control key or bypass inference policy.

Configuration defines the available catalog and service settings. Live governance narrows who may use those resources and how much they may consume. File changes require the documented restart; most access and budget edits are checked on the next operation.

Request decisions explain what Mission Control allowed and what happened. Trace observations explain execution. Usage accounts for physical work. Evaluations measure output quality. They answer different questions and have distinct permissions.

Explore a concept, then try it

Understand	Put it into practice
Organizations, Teams and keys	Make your first request
Models and tools	Use governed tools in a model request
Agents and deployments	Build your first Agent
Governance and limits	Configure budgets
Evaluation	Run an experiment
Configuration lifecycle	Review configuration

The glossary defines current terminology. See Current release for supported capabilities and exclusions.