The curator is your agent

"Curator" is a role, not a program. db.md ships no LLM runtime 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. The toolkit is deterministic file plumbing; the agent does the reasoning.

Bring your own harness

There is no curator binary to run and no provider to configure. 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.

No reference binary, by design

An earlier draft of db.md shipped a curator binary with a pluggable LLM backend. That is gone. The reasoning:

• Your harness is better than ours would be. A real agent harness already has retries, observability, cost tracking, and a model you trust. A bundled reference would always trail it.
• Zero AI in the toolkit. dbmd ships no provider SDKs, no API keys, and no model calls. Keeping the intelligence in your harness keeps the toolkit deterministic and its supply chain clean.
• The contract is what matters. The spec defines the behavior; the runtime is your choice.

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).