Experience

L6. Where a person observes and controls the company, and the one rule that keeps the UI out of the business.

1 min read Updated Aug 12, 2026

Experience

L6. The layer a person touches.

Mission Control is not a dashboard. A dashboard reports. This layer lets a person observe the company, direct work, approve an action and stop it.

L6 EXPERIENCE — read paths and write paths are separate, and only one of them mutates
L6 EXPERIENCE — read paths and write paths are separate, and only one of them mutates
PERSON
PERSON
READ PATH — every view is a read of one primitive
READ PATH — every view is a read of one primitive
Overview · Company · Work
company state, by domain
Overview · Company · Workcompany state, by domain
Agents · Workflows · Runs
the registries and every execution
Agents · Workflows · Runsthe registries and every execution
Approvals
the guaranteed floor for a decision
Approvalsthe guaranteed floor for a decision
Knowledge · Activity
documents, and the run event feed
Knowledge · Activitydocuments, and the run event feed
WRITE PATH — the only route, and it has no bypass
WRITE PATH — the only route, and it has no bypass
Command interface
one instruction, in plain words
Command interfaceone instruction, in plain words
Control API
the UI runs no business operation
Control APIthe UI runs no business operation
Policy admits the run
Policy admits the run
Run
agent or workflow
Runagent or workflow
L4 runs, steps and events
L4 runs, steps and events
L3 company state
L3 company state
observe
observe
direct
direct
one run row
one run row
through a tool
through a tool
run events
run events
read
read
LEGEND
LEGEND
entry — the person
entry — the person
deterministic plumbing
deterministic plumbing
a store the views read
a store the views read
ordinary component
ordinary componentText is not SVG - cannot display
L6 EXPERIENCE — read paths and write paths are separate, and only one of them mutates
L6 EXPERIENCE — read paths and write paths are separate, and only one of them mutates
PERSON
PERSON
READ PATH — every view is a read of one primitive
READ PATH — every view is a read of one primitive
Overview · Company · Work
company state, by domain
Overview · Company · Workcompany state, by domain
Agents · Workflows · Runs
the registries and every execution
Agents · Workflows · Runsthe registries and every execution
Approvals
the guaranteed floor for a decision
Approvalsthe guaranteed floor for a decision
Knowledge · Activity
documents, and the run event feed
Knowledge · Activitydocuments, and the run event feed
WRITE PATH — the only route, and it has no bypass
WRITE PATH — the only route, and it has no bypass
Command interface
one instruction, in plain words
Command interfaceone instruction, in plain words
Control API
the UI runs no business operation
Control APIthe UI runs no business operation
Policy admits the run
Policy admits the run
Run
agent or workflow
Runagent or workflow
L4 runs, steps and events
L4 runs, steps and events
L3 company state
L3 company state
observe
observe
direct
direct
one run row
one run row
through a tool
through a tool
run events
run events
read
read
LEGEND
LEGEND
entry — the person
entry — the person
deterministic plumbing
deterministic plumbing
a store the views read
a store the views read
ordinary component
ordinary componentText is not SVG - cannot display
The read path and the write path, drawn apart on purpose. A view reads one primitive. A mutation has one route: command interface, control API, policy, run.

Components

ComponentJob
OverviewThe state of the company on one screen. Metrics, exceptions and what is running now.
CompanyCompany state, by domain. The record view for every business entity, and the metric view for each domain.
WorkTasks, projects and goals. What is planned, and who owns it.
AgentsThe agent registry. Read a spec, edit it, disable it.
WorkflowsThe workflow registry, and the version history of each one.
RunsEvery execution, live and past. Steps, inputs, outputs, cost and errors.
ApprovalsThe approval center. Every pending human decision, and its deadline.
KnowledgeDocuments, playbooks and policies that the company holds.
ActivityThe feed of run events. What changed, who changed it, and why.
Command interfaceOne text box. A person writes an instruction, and an agent reads the intent.
Control APIThe only write path. It turns a request into a run or a record write.

Rules

  • The UI executes no business operation. It renders state and it sends requests. A UI that writes to the database directly bypasses policy, audit and the run record in one step.
  • Every mutation becomes a run or a record write, through the control API. There is no second write path, and no admin escape hatch.
  • The approval center is the guaranteed floor. A notification can fail to reach a person. A channel can fail to render a decision. This surface is the one place an approval always waits.
  • Every view is a read of one primitive. Runs reads runs. Activity reads run_events. Approvals reads approvals. A view that needs a new aggregate is a read model, never a new source of truth.
  • A dashboard is not a new surface. A revenue, product or errors dashboard is the Company view filtered to one domain, over metrics. One chart component serves all of them. A page per data source is the failure this rule prevents. See Metrics and connectors.
  • The intervene control is always reachable. A person can stop one run, disable one agent, or stop everything, from any screen.
  • The UI does not poll a tool. It subscribes to run events. A tool answers to the run, and the run answers to the UI.

What a person can do

Five verbs, and every screen serves one of them.

VerbSurfaceResult
ObserveOverview, Company, ActivityThe person sees the current state.
UnderstandRuns, KnowledgeThe person sees why the state is what it is.
DirectCommand interface, WorkflowsA new run starts.
ApproveApprovalsOne waiting run continues, or stops.
InterveneAny screenA run stops, an agent is disabled, or the fleet pauses.

Data model

This layer owns no table. It reads the tables of the layers below it, and it writes only through the control API.

One read model is worth building: an overview projection over runs, run_events and company state. It is a cache, and it is rebuildable from its sources.

Risks

RiskMitigation
A convenience write is added straight to the database, "just for the admin screen"The control API is the only route. This is checked in review, and row-level security holds even if review misses it
The activity feed grows until nobody reads itEvents carry a severity, and the feed defaults to exceptions
An approval waits behind a screen nobody opensEach approval has a TTL. Silence expires the request. Silence never becomes consent
The overview becomes a report, and the control verbs get buriedEvery screen must serve one of the five verbs. A screen that serves none is deleted

Open questions

  1. Does the command interface belong to one agent, or does it route to a role-specific agent for each domain?
  2. Can a person resolve an approval outside Mission Control, for example in Slack? If yes, the approval row is the contract and the channel is a rendering detail.
  3. Does the intervene control stop a run at the next step boundary, or immediately? A hard stop can leave a tool call half-done.
  4. Who may edit an agent spec, and does an edit apply to a run already in flight?

Diagram source. ac-docs/diagrams/mission-control-layers.drawio, page mission-control-experience. Edit that page, then run ./scripts/export-diagrams.sh mission-control-layers. Update this page and the diagram together.

mission-control
ui
control-plane
approvals
activity