Mission Control

Status: draft for review · Date: 2026-08-12

This is the high-level design. It shows the six layers, the policy plane, and the rules that hold them apart. Each layer has its own page with its components and its detail diagram. This page does not repeat them.

1. What Mission Control is

Mission Control is the internal Company OS. It is the human control plane over company state and over autonomous execution.

A person uses it to do five things.

Observe · Understand · Direct · Approve · Intervene

It is not a dashboard. A dashboard shows numbers. Mission Control operates the company through a mix of people, agents, workflows, company data and external systems.

Three properties set its scope.

Same blueprint, separate stack. Mission Control copies the layer model of the agentic platform, and shares its vocabulary and its rules. It shares no database, no run table and no deployment. Internal operations must not stop when the customer product stops. A customer must never reach an internal agent. The cost of this decision is real, and it is deliberate: two implementations of the same shape, kept in step by review.

2. Principles

1. One execution substrate. One run table, one status model, one event stream, one reaper.
2. Definitions are data, not code. An agent is a row. A workflow is a row. A tool is a row. A policy is a row.
3. Intelligence is not execution. An agent decides. A workflow sequences. A run executes. A trigger starts.
4. Knowledge is not memory. Knowledge is what the company knows. Memory is what happened before.
5. A capability is not its implementation. A tool is the contract. The service behind it can change.
6. An agent reaches the world only through a tool. It holds no credential, and it writes no SQL.
7. Company state is a first-class primitive. The CRM is one domain inside it, not the whole of it.
8. Policy is external to the agent. An agent must not decide its own authorization.
9. Human approval is a policy decision. It is not a branch in agent code.
10. Dependencies flow down. A layer knows the layer below it. It never knows the layer above it.
11. Prefer a declarative specification. A spec is easier to inspect, to version and to control than code.

3. How the system works

Six layers and one plane. Each layer is thin. The design is in how few of them there are, and in what each one refuses to do.

One request moves through Mission Control in eleven steps.

1. A person writes an instruction in Mission Control, or opens a proposal.
2. The control API turns the instruction into one request. The UI runs no business operation.
3. An agent reads the intent and the context. It answers, asks a question, or writes a brief.
4. A brief starts one run, for an agent or for a workflow.
5. Policy admits the run. It checks the principal, the agent and the account limits.
6. The orchestration layer resolves what to run: the agent version, its skills and its tools.
7. The context builder reads company state, knowledge and memory. It returns one brief.
8. The run executes. Each step is durable, so a crash resumes rather than restarts.
9. The agent calls a tool for anything outside its own context. Policy answers allow, deny or require approval.
10. On require approval the run writes an approval row and waits. A person decides in the approval center.
11. The tool writes to company state. Run events stream back to Mission Control.

A trigger starts the same flow at step 4, with no person. Step 5 still runs.

The run writes back to company state through tools. That is what the next brief reads.

4. The layers

Policy has no number, because it is not a step in the path. Nothing passes through it. It is asked one question at three points, and it answers in one word.

One more page cuts across every layer. Metrics and connectors is a worked example: three vendors, one metric pipeline, three views, and no new machinery. Read it to see how a feature is supposed to land.

5. Core primitives

Fourteen nouns carry the whole system. A reader who knows these knows Mission Control.

6. Data model

Eighteen tables carry the platform, plus the company state domain tables. Every definition is a row, so a new agent, workflow, tool or rule is a write and not a deploy.

Company state adds one table for each business entity: companies, people, opportunities, projects, tasks, goals, metrics, activities, decisions. Each one has exactly one owning domain. See Company context.

metrics and external_refs carry every external number and every vendor id, whatever the source. Their shape is on Metrics and connectors.

Three tables that do not exist are as important as the ones that do.

• No permission table. An agent's permission surface is its tool list and its scopes. A person's rights are their roles. The plane computes the intersection, and stores neither side.
• No audit table. run_events and policy_decisions are the audit trail. A third copy would drift.
• No working memory table. Working memory is the run. Episodic memory is a query over runs and run_events.

7. Dependency rules

L6 Experience
   ↓
L5 Intelligence
   ↓
L4 Orchestration
   ↓
L3 Company context
   ↓
L2 Tools and integrations
   ↓
L1 Foundation

A layer calls the layers below it, and not only the adjacent one. A workflow step at L4 calls a tool at L2 with no agent in the path. A lower layer never calls a higher one. It emits an event instead, and something above it listens.

Two consequences carry most of the value.

An agent knows no infrastructure. It does not know PostgreSQL, Redis, a Slack SDK, an HTTP controller or a UI component. It knows a tool.

Agent → Tool → Service → Infrastructure

The UI mutates nothing directly. Every change of state passes through the control API and lands as a run or a record write.

UI → Control API → Agent, workflow or run → Tool → Company state

There is one deliberate exception. The context builder reads company state, knowledge and memory directly, because it is deterministic infrastructure and not a capability an agent chooses. Both paths obey the same row-level security.

8. Key decisions

9. Not building

• A second orchestration engine. A workflow step is a durable step on the engine we already run.
• A second run table.
• A pause and resume checkpointer of our own.
• Agent hierarchies deeper than one hop.
• A general policy language, or a fourth decision beyond allow, deny and require approval.
• A permission table.
• A separate audit store.
• A store for working memory or for episodic memory.
• A knowledge graph. Company state is the entity model.
• A retrieval agent. The context builder is deterministic.
• A vector database. The vector index is an extension of the database we already run.
• Direct database access for an agent, in any form.
• Raw REST routes exposed to a model.
• Business logic in the foundation layer.
• An analytics product. We store the numbers the company is operated on, and we link out for the rest.
• A mirror of a vendor's object model. We map a vendor id, and we store no vendor record.
• A dashboard per data source. A source is a connector, and a dashboard is the Company view, filtered.

10. End-to-end example

The instruction is one sentence.

Find promising companies, enrich them, and add the qualified ones to the CRM.

The path is eleven hops, and every one of them is a primitive from section 5.

Person
  → Mission Control            L6  the instruction becomes one request
  → Agent                      L5  read the intent, write a plan
  → Workflow                   L4  four ordered steps
      ├── Research             L4  step run, calls the web search tool
      ├── Enrichment           L4  step run, calls the company data tool
      ├── Qualification        L5  step run, agent reasoning, no tool
      └── CRM update           L2  step run, calls the CRM tool
  → Policy                     ··  allow, or require approval
      └── Approval             L6  a person decides in the approval center
  → CRM tool                   L2  the write happens once, and it is idempotent
  → Company state              L3  the record changes
  → Run events                 L4  the change appears in Mission Control

Nothing in this path is specific to prospecting. Change the four steps and the same machinery runs a hiring loop, a monthly close or an incident review.

11. What comes next

The layers are settled. The contracts between them are not, and they decide whether the system stays modular.

Agent → Workflow → Run → Context → Policy → Tool → Company state

Each arrow is a schema that two layers must agree on. Each layer page ends with the open questions for its own arrow.

12. References

• Agentic platform — the customer-facing system on the same blueprint
• Mission Control product design — the product surface and the ops agent fleet