Company context
L3. Company state, knowledge and memory are three different things. One deterministic builder turns them into one brief.
Company context
L3. The layer that knows.
Three stores, and they are not the same store. Company state is what is true now. Knowledge is what the company holds. Memory is what happened before.
Components
| Component | Job |
|---|---|
| Company state | The structured state of the business, by domain. |
| Knowledge | Durable documents the company holds, and their retrieval index. |
| Memory | What happened before, and what was learned. |
| Context builder | Read the three stores and return one brief for one run. |
Company state
Company state is the structured state of the business. It is one model with several domains. Each entity has exactly one owning domain.
Company state
├── CRM companies · people · leads · opportunities
├── Product features · usage · adoption · releases
├── Engineering errors · incidents · deploys · latency
├── Operations tasks · projects · processes · decisions
└── Finance revenue · costs · transactions
The CRM is one domain, not the whole model. A CRM-shaped company model has no place to put a goal, a project, a release or a decision, so those facts end up in documents and in spreadsheets. Then no agent can read them.
Cross-domain entities sit above the domains: goals, metrics and activities each refer to records in any domain.
Metrics and external ids
Two tables carry everything that comes from outside.
metrics holds one number, for one key, at one period. Every source writes the same shape, so one query and one chart component serve finance, product and engineering alike.
metric key · source · domain · grain · at · value · unit
dimensions · definition · observed_at · source_ref
external_refs maps one of our records to one vendor id. It is what lets a CRM company know its Stripe customer, without mirroring any part of Stripe. A vendor record is never copied into company state.
The full worked example, including the three connectors and the ingest rules, is on Metrics and connectors.
Knowledge and memory
They answer two different questions, and mixing them is the common failure.
| Knowledge | Memory | |
|---|---|---|
| Question | What do we know? | What happened before? |
| Source | A person or a system wrote it down | A run produced it |
| Examples | Company docs, product docs, policies, playbooks, research, meeting notes | A preference, an observation, a past decision, a correction |
| Lifetime | Until someone changes it | Until it is superseded, or it expires |
| Write path | Direct, by a person or an ingest job | Proposed by a run, confirmed before it persists |
They may share storage. They must not share meaning. A playbook that an agent invented is not a playbook.
Memory has four kinds, and only one of them needs a table.
| Kind | Where it lives |
|---|---|
| Working memory | The run. It ends when the run ends. |
| Episodic memory | A query over runs and run_events. |
| Durable memory | The memories table: one preference or observation. |
| Decision memory | A decisions record in company state. A decision is a business fact, not a note. |
The context builder
An agent must not receive one large static context. The builder assembles a brief for each run.
run starts
│
▼
┌─────────────────┐
│ Context builder │◄──── context policy, from the agent row
└────────┬────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Company state Knowledge Memory
│ │ │
└──────────────┼──────────────┘
▼
one brief, ranked and trimmed to budget
│
▼
Agent
The builder is deterministic. A context policy on the agent row states what to retrieve, from where, and how much. The agent does not choose. An agent that decides what to retrieve is a second reasoning hop, and the one-hop rule forbids it.
The builder is the one component that reads company state directly, and not through a tool. It is deterministic infrastructure, not a capability an agent selects. It obeys the same row-level security as every tool.
Precedence
Three stores can disagree about the same fact. The order is fixed.
Company state beats Knowledge beats Memory
Without an order, an agent picks the version that reads best. With it, a stale document never overrides a live record, and a remembered preference never overrides a written policy.
Rules
- Each fact has one owner. Company state owns business facts. Knowledge owns documents. Memory owns preferences and observations.
- A run writes to company state only through a tool. The builder reads directly. Nothing writes directly.
- A memory is proposed, then confirmed. A run proposes. A person or a rule confirms. An unconfirmed memory never enters a brief.
- A brief carries its provenance. Every claim in a brief names its source record, so a person can check it.
- A brief has a budget. The policy sets a token ceiling, and the builder trims to it. It does not overflow and truncate at random.
- Nothing in this layer calls a model, except the embedder. Ranking is a query. Retrieval is a query.
Data model
| Table | Holds |
|---|---|
documents | One durable knowledge document, its source, its owner and its version. |
document_chunks | One embedded passage of a document, for retrieval. |
memories | One preference or observation, its scope, the run that proposed it, and its confirmation state. |
Company state adds one table per business entity: companies, people, opportunities, projects, tasks, goals, metrics, activities, decisions, plus external_refs for the vendor id of any of them.
Working memory and episodic memory add no table. Working memory is the run. Episodic memory is a query over runs and run_events. A copy of either would go stale.
Risks
| Risk | Mitigation |
|---|---|
| Memory poisoning: a run writes a false observation, and later runs read it as fact | Propose and confirm on the write path, provenance on every memory, and an expiry |
| Knowledge goes stale, and an agent quotes a policy that was replaced | A document carries an owner and a review date. Precedence puts company state above it |
| The brief grows until it costs more than the work | A token budget per agent, enforced by the builder |
| An agent reaches company state directly, "for performance" | Only the builder reads directly. Every write is a tool call. Row-level security holds either way |
| Domains multiply until company state is a second CRM per team | One owning domain per entity, decided when the entity is added |
| A vendor record is copied in "just this once", and it goes stale | external_refs maps an id. A record detail is read live, and never stored |
Open questions
- Who confirms a proposed memory? A person for every one is too slow, and a rule for every one is too loose.
- What is the expiry for a durable memory? A preference is not a fact, and it should decay.
- Does knowledge ingest run as a workflow, so it gets retry and audit for free?
- How does the builder rank across three stores with one score? A single relevance score across a record, a passage and an observation is not obviously meaningful.
Diagram source. ac-docs/diagrams/mission-control-layers.drawio, page mission-control-context.
Edit that page, then run ./scripts/export-diagrams.sh mission-control-layers.
Update this page and the diagram together.