Roles and Journeys¶
Target architecture — not the current operating contract
The work profiles below are product direction, not implemented roles. See Roles and permissions for the eight built-in role presets, bounded custom roles and their exact scopes.
Current operators investigate governed requests through Observe → Requests, Traces, Sessions and Usage and assess quality under Evaluate. Mission Control does not create a Run resource today; Run Explorer steps below remain future journey design.
Work profiles¶
People may hold several work profiles, but sensitive operations can still require separation of duties. Profiles shape navigation, defaults, attention queues, and available actions; the Control Kernel remains authoritative for each resource and operation.
| Profile | Can primarily | Cannot gain implicitly |
|---|---|---|
| Developer | Design, import, test, evaluate, version, and submit Agents, Workflows, AI Applications, and Retrieval Collections; request model and Connector capabilities | Production promotion, policy publication, Connector certification, secret access, or self-approval unless separately granted |
| Administrator | Configure SSO mappings, workload identity, environments, model resources, MCP Servers, grants, retention, redaction, secret references, gateways, and modules | Policy-owner or approver authority simply because the user administers the platform |
| Operator | Monitor health, Runs, queues, exceptions, tasks, cost, evidence gaps, and incidents; perform authorized retry, compensation, suspension, and recovery actions | Definition editing, policy publication, evidence alteration, or bypass of failed controls |
| Policy Owner | Author, test, simulate, review, publish, bind, explain, and analyze policy and approval routes | Approval of a conflicting request, production resource promotion, or execution outside the published policy |
| Auditor | Inspect permitted registry, versions, provenance, decisions, approvals, Runs, evidence, evaluations, incidents, corrections, Outcomes, and exports | Mutation of operational state or access to captured content outside its governed purpose |
Estate onboarding¶
| Step | User experience | Owning component |
|---|---|---|
| 1. Establish environment | Administrator creates environment scope, network posture, retention, redaction, and enabled-module controls | Control Kernel Platform Configuration and Environments |
| 2. Connect human identity | Administrator maps customer SSO groups to work profiles and tests effective access | Identity and Access |
| 3. Establish workload identity | Administrator defines short-lived workload credential rules and environment-scoped grants | Identity and Access |
| 4. Register model access | Administrator registers provider and deployment references, creates a Virtual Model, defines routing, budget, guardrails, and health checks | Model Management |
| 5. Register MCP Server | Administrator records endpoint, transport, owners, network path, environment, and customer-secret reference | Connectors and MCP Catalog |
| 6. Discover and classify tools | Administrator or designated owner imports typed tools and classifies each as Data, Decision, or Action | Connector Catalog and Classification Manager |
| 7. Certify and promote tools | Owners test schemas, policy fixtures, representative results, failure, idempotency, and version behavior; separated reviewers approve production | Connector Certification, Control Kernel lifecycle, and Policy Studio |
| 8. Connect an external Agent | Developer selects identity, environment-scoped grants, policy, and a narrowed Agent key; runtime version fields remain observed only | Agent Studio code interface and Resource Registry |
| 9. Bind authority | Administrator and Policy Owner establish grants, policy bindings, approval routes, and environment access | Identity and Access plus Policy Studio |
| 10. Prove governed operation | Developer executes a test through both gateways; Operator confirms Trace, cost, decision, Connector and model evidence | Gateways plus Observability and Evaluation |
Separation of duties can prevent the same actor from registering a high-risk Action Connector, defining its policy, certifying its version, approving its production promotion, and approving its first live use.
Agent creation and release¶
| Step | User experience | Owning component |
|---|---|---|
| 1. Define | Developer creates Agent purpose, typed inputs and outputs, instructions, owners, limits, and termination behavior | Agent Designer |
| 2. Request capabilities | Developer selects a Virtual Model, Retrieval Collections, Connectors, and delegation rights; denied or approval-required requests show reasons | Agent Studio Capability Selector, Identity and Access, Policy Studio |
| 3. Configure knowledge | Developer binds an access-aware Collection with source and citation expectations | Retrieval |
| 4. Test | Developer runs scenarios and inspects declared output, Model and Connector calls, decisions, costs, citations, and typed failures | Agent Test Console, gateways, Run Explorer |
| 5. Evaluate | Developer runs versioned quality, safety, Connector-selection, Retrieval, latency, cost, and Outcome criteria | Evaluation Workspace and Evaluation Center |
| 6. Submit | Developer freezes an immutable review version with test, evaluation, access, policy, and provenance evidence | Agent Studio Release Manager and Control Kernel lifecycle |
| 7. Review and promote | Separated reviewers approve definition, capabilities, policy, and environment promotion | Resource review, Policy Studio, Approvals, Deployments |
| 8. Deploy managed release | Current managed deployments publish immutable versions; external code independently uses ordinary virtual keys | Native Agent Runtime or future Agent Builder release registry |
| 9. Operate | Operator sees current Traces, request outcomes, usage, cost, health and evaluation results; incidents, Outcomes, and Run Explorer remain target work | Operations and Assurance |
Agent Studio owns the definition and native reasoning-session contract. Automations owns any surrounding durable process. A release does not become active merely because its author passed local tests.
Governed action¶
| Step | User experience | Owning component |
|---|---|---|
| 1. Trigger | User, event, API, Application, Agent, or Workflow creates a Run with identity, environment, version, Trace, and business references | Application service or runtime plus Control Kernel |
| 2. Analyze | Agent resolves a Virtual Model and performs inference through the Model Gateway | Agent runtime, Model Management, Model Gateway |
| 3. Request capability | Runtime requests a pinned Action Connector with typed arguments and stable idempotency key | Connector client and Connector Gateway |
| 4. Decide | Gateway validates input and asks Policy Studio to evaluate principal, resource, operation, context, and history | Connector Gateway and Policy interface |
| 5. Deny, allow, or pause | A deny returns a typed reason; allow proceeds; approval_required creates a durable request and releases execution capacity |
Control Kernel Policy and Approvals |
| 6. Review | Eligible approver sees scope, risk, value, policy reason, separation of duties, evidence, expiry, and rationale requirement | Approval Center |
| 7. Re-evaluate | After approval or delay, gateway checks current identity, grant, policy, resource and Connector version, health, context, and idempotency | Connector Gateway and Control Kernel |
| 8. Execute once | Gateway invokes the MCP tool, validates and normalizes the result, and records recoverable evidence intent | Connector Gateway and MCP Server |
| 9. Assure outcome | Operator follows Action, cost, evaluation, incident, correction, and business Outcome from the Run | Run Explorer, Evaluation Center, Evidence and Assurance |
The requester cannot approve a separated Action. Approval does not override a later denial or changed context, and a duplicate resume cannot execute the business effect twice.
Incident reconstruction¶
| Step | User experience | Owning component |
|---|---|---|
| 1. Detect | Operator receives a degradation, error-rate, queue, policy, evidence, cost, evaluation, or Outcome alert with affected scope | Live Operations and monitoring |
| 2. Scope | Operator opens the Incident Workspace and sees affected environments, resources, versions, consumers, Runs, and control guarantees | Observability and Evaluation |
| 3. Traverse | Operator moves from an affected Run through Agent or Workflow, model route, Connector version, decisions, approvals, retries, exceptions, and evidence gaps | Run Explorer and shared resource pages |
| 4. Compare changes | Operator correlates deployment, policy, routing, schema, secret, environment, or infrastructure changes without assuming causation | Activity, Versions, Policy Decision Explorer, and Incident Workspace |
| 5. Contain | Authorized, separated actors suspend a resource, open a circuit, pause a Workflow, roll back an approved version, or restrict a route | Resource lifecycle, gateways, Automations, Deployments, Policy Studio |
| 6. Recover | Operator verifies restored health, drains or routes exceptions, resumes safe work idempotently, and confirms evidence publication | Reliability controls and Operations Console |
| 7. Record | Incident owner captures impact, mitigation, recovery, corrections, affected Outcomes, and follow-up controls | Incident Workspace and Evidence and Assurance |
Operators can coordinate containment but do not automatically gain policy-publication, approval, or definition-authoring rights. Corrections append evidence and preserve the degraded interval and original decisions.
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.