Skip to content

Platform Architecture Overview

Target architecture — not the current operating contract

This page preserves product direction. For the implemented two-service topology, see the current release.

Mission Control is organized as three logical planes joined by explicit contracts. The planes are product and security boundaries; they do not require one independently deployed service per box in the first release. Canonical terms are defined in the glossary.

System model

Plane Responsibility Primary components
Experience Presents authenticated, role-aware management and published end-user experiences. Mission Control Console, published AI Applications, Embed SDK
Control Owns durable identity, authority, configuration, lifecycle, provenance, evidence, evaluation, and product definitions. Control Kernel, Agent Studio, Automations, Retrieval, Model Management, Policy Studio, Operations and Assurance
Execution Runs latency-sensitive or durable work through enforced boundaries. Native Agent Runtime, Workflow Runtime, Indexing Workers, Model Gateway, Connector Gateway

Customer and provider systems remain outside these planes: external agent runtimes, customer CI/CD, customer SSO, the customer secret manager, model providers, and MCP servers. They connect through narrow, versioned interfaces.

flowchart TB
    subgraph XP["Experience plane"]
        Console["Mission Control Console"]
        Apps["Published AI Applications"]
        Embed["Embed SDK"]
    end

    subgraph CP["Control plane"]
        Kernel["Mission Control Kernel"]
        AgentStudio["Agent Studio"]
        Automations["Automations"]
        Retrieval["Retrieval"]
        ModelManagement["Model Management"]
        PolicyStudio["Policy Studio"]
        Operations["Operations and Assurance"]
    end

    subgraph EP["Execution plane"]
        AgentRuntime["Native Agent Runtime"]
        WorkflowRuntime["Workflow Runtime"]
        IndexWorkers["Indexing Workers"]
        ModelGateway["Model Gateway"]
        ConnectorGateway["Connector Gateway"]
    end

    subgraph EXT["Customer and provider ecosystem"]
        ExternalAgents["External Agent Runtimes"]
        CICD["Customer CI/CD"]
        Models["Model Providers"]
        MCP["MCP Servers"]
        SSO["Customer SSO"]
        Secrets["Customer Secret Manager"]
    end

    Console --> Kernel
    Apps --> Kernel
    Embed --> Apps
    AgentStudio --> Kernel
    Automations --> Kernel
    Retrieval --> Kernel
    ModelManagement --> Kernel
    PolicyStudio --> Kernel
    Operations --> Kernel
    Kernel --> SSO
    Kernel --> Secrets
    AgentStudio --> AgentRuntime
    Automations --> WorkflowRuntime
    Retrieval --> IndexWorkers
    AgentRuntime --> ModelGateway
    AgentRuntime --> ConnectorGateway
    WorkflowRuntime --> AgentRuntime
    WorkflowRuntime --> ConnectorGateway
    IndexWorkers --> ConnectorGateway
    ExternalAgents --> ModelGateway
    ExternalAgents --> ConnectorGateway
    CICD --> Kernel
    ModelGateway --> Models
    ConnectorGateway --> MCP

The management experience and Control Kernel may begin as a modular application with explicit internal interfaces. Gateways and latency-sensitive workers remain independently deployable so enforcement, scaling, and failure isolation do not depend on the management process.

Primary flows

Build and release

  1. A developer creates or imports a definition in a Studio module.
  2. The Control Kernel registers its identity, owners, requested capabilities, policy bindings, and lifecycle state.
  3. Tests, policy fixtures, and evaluation gates produce attributed results.
  4. Review and access decisions authorize promotion of an immutable version.
  5. Current managed deployments pin immutable versions; external runtimes use ordinary user/service virtual keys and may report observed version metadata without establishing authority.
  6. The deployment appears in Estate Inventory with its provenance, health, access, policy, activity, and evidence links.

Governed execution

  1. A user, event, API, application, agent, or workflow triggers a registered resource version.
  2. The runtime resolves a short-lived workload identity and propagates the run and trace context.
  3. Every inference request uses the Model Gateway; every MCP request uses the Connector Gateway.
  4. The gateways obtain access and contextual policy decisions and create a durable approval when required.
  5. An approved provider deployment or pinned MCP tool version executes.
  6. Trace, decision, usage, cost, action, evaluation, and outcome evidence becomes available to Operations and Assurance.

External-agent onboarding and execution

  1. The owner registers the Agent identity, grants environment-scoped authority, and issues a narrowed Agent key.
  2. The current release uses ordinary user/service virtual keys for external code and separate secretless execution access for managed deployments. Catalog, Team allowance and key policy govern API work independently from human roles.
  3. Policy bindings and environment permissions are reviewed before activation.
  4. The external runtime uses gateway clients, propagates W3C Trace context, and emits ordinary OpenTelemetry observations beside governed evidence. A future Run layer may add a higher-level execution identity.
  5. Current external code and managed deployments appear in the same Observe workspace, and evaluation runs under Evaluate; the broader Estate Inventory, Run Explorer, incident, and evidence views remain target architecture.

Retrieval

  1. A registered Data Connector accesses an approved enterprise source through the Connector Gateway.
  2. Governed indexing creates approved derived content, citations, ACL metadata, and freshness state inside the customer boundary.
  3. An access-aware query applies current caller, source, collection, environment, and data-class permissions.
  4. Ranked passages and citations are returned to a registered agent or AI Application.
  5. Run evidence retains citation references rather than unnecessary source payload copies.

Hybrid workflow

  1. A trigger creates a durable Workflow Run.
  2. A Data Connector obtains current context.
  3. An agent task performs probabilistic analysis through the Model Gateway.
  4. A side-effect-free Decision Connector evaluates or validates the proposal.
  5. A deterministic branch applies the declared result.
  6. Policy may create a Governance Approval before an Action Connector changes enterprise state.
  7. The workflow records execution state, compensation or exception handling, cost, and the business outcome.

Boundary rules

  • The Control Kernel owns control semantics and durable metadata; it does not execute agent business logic, perform inference, invoke MCP tools, render applications, or become an enterprise source system.
  • Browsers and embedded clients call authenticated application services. They never call model providers, gateways, or MCP servers directly.
  • A run is governed only when every provider and MCP operation uses the appropriate enforced gateway. Gateway failure does not enable bypass.
  • Enterprise source systems remain authoritative. Retrieval contains approved derived content, not a replacement system of record.
  • Published resource versions are immutable, and all execution and evidence references identify the exact version used.
  • Logical data boundaries, access rules, retention semantics, and ownership remain product contracts even when physical storage is consolidated initially.

Detailed contracts

Current governance mapping

The current source release uses Organizations, Teams, real user/service-account virtual keys and separate human management roles. Agent is managed application content; deployments own secretless execution access and publisher funding. Observe uses Requests, Traces, Sessions and Usage with separate metadata/content/export permissions. Historical identity terms in this target proposal are not the operating contract. See Current release.