Capabilities · 0. What the daemon gives you
This set answers the one question the rest of the documentation does not: what a capability is for, why it works the way it does, and what changes for you and for your agents once it is on. The other eighty-two chapters on this site are reference and how-to. They tell you what a thing is and how to call it, completely and accurately. They do not tell you why it exists, and that is the gap this set fills.
If you want the route list, the flag list or the exact response shape, you are in the wrong set and every explainer here ends with a link to the right one.
0.1 What this set is
Explanation, and only explanation. There are no steps here, no route tables, no environment-variable tables, no request or response schemas. One rule governs every page:
An explainer states a fact once and then links. It does not enumerate.
Every capability is written as the same six blocks, in the same order:
- What it does, in two to four sentences.
- Why it works this way, which is the problem it removes, the alternative that was rejected, and the trade-off that was accepted.
- What changes for you, as an operator and as an agent, concretely.
- What it does not do, stated as plainly as what it does.
- Turn it on, where there is something to turn on.
- Where the detail lives, which is at most three links, at least one of them into the reference set.
The middle two blocks are the reason the set exists. A page here that told you only what a capability is would be a reference page in the wrong directory.
0.2 Which plane this documents, and the word "MCP"
This set documents the Crux Daemon, the corecruxd process that runs on a machine you control. So do the crux-daemon-internals, api, extending, operations, sdk, platform and contributing sets.
The site also carries a second, older documentation voice covering the VaultCrux Frontdoor, a different service with different ports, different auth headers and a different tool surface. The pages mcp-architecture, api-auth, auth, skill, ingestion-lifecycle, citation-credit-model, economy-marketplace and the various *-quickstart pages belong to that voice.
The collision that matters is the word MCP. In this set, "MCP" always means the daemon's own Model Context Protocol listener, the one your agent connects to and whose tools are named store_fact, query_facts, coord_announce and so on. It is a separate listener on a separate port from the daemon's HTTP API. In the Frontdoor pages, "MCP" means a different service entirely, with its own port and its own JSON-RPC endpoint. If a tool name or a port number in your notes does not match what you read here, check which of the two you are actually pointed at before you debug anything else. Compare MCP Architecture, which is the Frontdoor service, against the daemon's MCP overview, which is this one.
0.3 The daemon in plain English
One program, running on your machine, holding what your agents know.
Everything an agent remembers here is either a fact or a document. A fact is a short written statement with three parts, a subject, an attribute and a value, appended as one line of JSON to a file in a directory you own. Documents are different: their content lives in binary segment files, written by different code with much stronger integrity machinery. Confusing the two is the most common way to be wrong about this daemon, and the split runs through the whole set: chapter 1 is about facts, and most of chapter 3 is about the difference between searching one and searching the other.
Around that store sit the other thirteen families. Retrieval decides what comes back and how much of your context window it costs. Sessions and handoffs carry work across a restart or across agents. Coordination lets several agents on the same tree see each other. Receipts record what was stored and retrieved, so a claim about the past can be checked later. Identity decides who is calling. Cost tells you what was spent. Sync, packs and lenses connect the box to everything else.
There are three ways in, an HTTP API, the MCP listener and a gRPC data plane, plus a command-line tool and a browser console served by the daemon itself. Which door you use changes the vocabulary, not the capability.
The problems this set is organised around are the ones you already have: agents that forget between runs, two agents that believe opposite things, recall that spends the whole context window before the work starts, and a fleet whose output you cannot reconstruct afterwards. Each family is named for its problem, not for its module.
0.4 How to read a status line
Every explainer opens with three lines. They look like this:
> Status · FLAG CORECRUXD_COORD, default on
> Reached through · MCP coord_announce · POST /v1/coord/announce · Console → Rings › Live board
> Who it is for · agentThe status is the important one, and it is not decoration. This documentation set was written against a full audit of the running code, and the status on each explainer is reproduced from that audit rather than re-derived from a feature list.
| Status | What it means | How to read the prose |
|---|---|---|
SHIPPED | In the default code path today | Present tense. It is running on your box now. |
FLAG | Built and gated. The flag and its default are named in the first sentence | If the default is off, it is off on your machine until you set it. If the default is on, only an explicit disable turns it off. |
STUBBED | The surface exists, nothing runs behind it | Said plainly, with the missing part named. |
DECLARED-NOT-WIRED | The code exists and is tested, but nothing in the running daemon calls it | Never present tense. It is library code, not behaviour. |
NOT-ACTIVE | Configured off and unreachable in this build regardless of configuration | Never present tense, and the reason is given. |
Two conventions follow from that. A capability whose library half is shipped and whose tool half is gated is written as shipped with the gate named, because the behaviour exists and the door is what is closed. And where a capability carries a standing honesty statement, for example that a receipt is a verifiable record of what was stored and retrieved rather than an attestation of what an agent did, that statement is reproduced word for word rather than paraphrased into something friendlier.
0.5 Who each track is for
Each chapter carries a track. The track does not gate content; it decides which bullet leads in the What changes for you block, and it tells you whether the chapter is describing a decision you make or a thing your agent does.
| Track | Read it as | Chapters |
|---|---|---|
both | Configured by a person, used by an agent | 0, 1, 2, 5, 10, 11, 13, 15 |
agent | Something your agent does; you read it to understand what you are watching | 3, 4 |
human | A decision a person makes, usually once | 6, 7, 8, 9, 12, 14 |
If you are running a fleet and are accountable for reconstructing its work, start with the human chapters. If you are a solo developer whose agents forget and contradict each other, start with 1, 2 and 3 in that order. If you are the agent, chapters 3 and 4 are the ones that change how you should call this thing.
0.6 The chapter map
Fourteen capability chapters, one per family, plus this index and a status appendix.
| # | Chapter | Track |
|---|---|---|
| 0 | What the daemon gives you: the mental model and how to read a status | both |
| 1 | Memory that persists | both |
| 2 | Memory that stays true | both |
| 3 | Finding things without burning the context window | agent |
| 4 | Continuity: sessions, precedents, handoffs, constraints | agent |
| 5 | Running a fleet: work, coordination, leases, projects | both |
| 6 | Evidence: receipts, observation, verification, and their limits | human |
| 7 | Who is calling: identity, access and capability | human |
| 8 | What it costs: cost, quota, metering, entitlements | human |
| 9 | Leaving: export, import, custody and erasure | human |
| 10 | Bringing your own systems: sync and connectors | both |
| 11 | Making it do more: packs, external tools, substrate, lenses | both |
| 12 | Operating it: lifecycle, config, health, console | human |
| 13 | Reaching it: HTTP, MCP, gRPC, CLI, hooks, SDKs | both |
| 14 | Trusting the build: supply chain, tests, release, licence | human |
| 15 | Status appendix: every capability, its status, its flag, its default | both |
Chapters 4 to 15 are listed here by number and title; the navigation group carries their links.
Reading order. Chapters 1, 2 and 3 are the product's actual argument and are worth reading in sequence: what gets written down, how it stays true, and what it costs to get it back. After that, jump by role. A risk reviewer goes to 6 and 7. An operator goes to 12 and 13. A fleet lead goes to 5, 9 and 8. An evaluator who wants the whole surface in one screen goes straight to 15, which is a single table of every capability with its status, its flag and its default, and is the only page in the set that deliberately duplicates data from elsewhere.
0.7 What this set will not do
It will not list routes, flags or fields. Those are complete elsewhere and duplicating them creates a second copy that drifts.
It will not quote a benchmark number without naming its corpus and the commit it was measured at. A number without that provenance is dropped rather than softened.
It will not describe a capability without its limit. Where a limit weakens the page, the limit still ships; several explainers here spend more words on the boundary than on the promise, and that is deliberate.
Sources
- Register and mental model for the fact store: daemon/10 §10.0.
- The two substrates, stated once: daemon/10 §10.1.
- The daemon process, its three listeners and its four verifiable properties: daemon/00 §0.1.