The curator is your agent

"Curator" is a role, not a program. db.md ships no model and no API keys. Any agent harness you already use, whether Claude Code, Codex, or your own loop, plays the curator role. It reads the spec, follows the curator contract, and operates the store through dbmd subcommands. Every dbmd verb is deterministic file plumbing; the agent does the reasoning.

Bring your own harness

The usual path runs no separate curator process at all: you load the spec into whatever agent you have and point it at the store.

# capture the canonical spec, then load it into your harness's system promptdbmd spec > /tmp/dbmd-spec.md

That gives the agent the format, the recognized types, the curator contract, the session lifecycle, and the validation vocabulary for the current session. Persistent setup is harness-specific: place the skills/db-md/SKILL.md file where your agent reads skills, or configure the harness to include dbmd spec. Per-store overrides come from DB.md on every operation.

The behavior contract

An agent acting as curator:

1. Knows the spec, loaded into the current harness context via dbmd spec or a persistent skill.
2. Reads the store's DB.md on every session: frontmatter for identity, plus the ## Agent instructions, ## Policies, and ## Schemas sections for per-store overrides.
3. Warms up with dbmd log tail to see what was done recently and avoid duplicate work.
4. Extracts atomic facts from new sources into records/ as meta-type: fact records. An email becomes a meeting record and a contact record. Every created file gets a summary in its frontmatter.
5. Captures ephemeral testimony as a source, source-first. When a fact arrives only in conversation, with no document behind it, the agent writes a note source under sources/notes/ (with told_by) at the moment of the create or update it drives, so the asserted fact has an evidence record to trace to. An unsaved conversation cannot be reconstructed later; a persistent document always can.
6. Synthesizes conclusion records (meta-type: conclusion) — profile, concept, playbook, theme, synthesis, account records that synthesize across records and sources, with dense full-path wiki-links. Conclusion records are single-voice: one curator reconciles them.
7. Maintains cross-references. A person's profile conclusion links to the contact record, the company record, and the meeting records.
8. Flags contradictions when two sources disagree, rather than silently picking a winner.
9. Appends to log.md on every action and lets the write commands keep index.md current. There is no rebuild step in the normal loop.

The agent does not delete files in sources/ (evidence the operator deletes explicitly), does not edit DB.md (operator-owned), and does not rewrite past log.md entries (the log is append-only).

Policies are enforced, not just remembered

The frozen pages and ignored types you declare in DB.md ## Policies are checked by the toolkit. A write command against a frozen path fails with a policy-refusal error, so the agent doesn't have to hold the list in its head. It gets told when a write is out of bounds and routes around it or escalates to the operator.

When you have no harness to bring

Your own agent is the better curator: it already has the retries, the observability, the cost tracking, and the model you trust. So that is the default, and the toolkit stays out of the way.

But some callers cannot host an agent at all: an app talking to the store, a machine with a model and no coding agent on it. For those, dbmd carries a deliberately tiny harness of its own, whose only tools are the same verbs above. It is a scoped fallback, not a coding agent: with no shell at any level it cannot install anything, run a build, or check its own work. Your agent stays the better curator, and this is the doorbell for when there is not one.

dbmd ask   "which contracts renew this quarter?"   # read verbs onlydbmd do    "mark the Lumio invoice paid and log it"  # adds the write verbs

The verb is the permission. ask has no write tools at all, so content injected through an ingested source can produce a wrong answer and nothing further. do writes only through the same dbmd verbs you would run by hand, so schema checks, frozen pages, link-aware deletes, and the store log all still apply. There is no shell tool at any level.

The model stays yours: a local server is found automatically (Ollama, LM Studio, llama.cpp), an API key works through --provider, and a subscription signs in with dbmd login codex or dbmd login anthropic (which runs Anthropic's own ant auth login). --effort sets how hard it thinks, from off through max, translated to whatever the provider calls that. What has not changed is the principle underneath:

• No provider SDKs, no bundled model, no default vendor, and no endpoint baked into the binary. The one surface that calls a model calls the one you configured, only when you invoke it.
• Keys never live in a store. They are read from the environment; a ChatGPT subscription token lives in the toolkit's own state directory, and an Anthropic session is not copied at all — it stays owned by Anthropic's CLI, which mints a short-lived token per request.
• The contract is what matters. The spec defines the behavior; the runtime is your choice, and the built-in one is a convenience, not a requirement.

Full contract

The complete curator contract and the six-step agent session lifecycle live in the spec: github.com/carloslfu/db.md/blob/main/SPEC.md (§ The curator contract, § The agent session).