Capture what you learn

Capture is the half of the loop that makes the other half worth doing. A question answered and never written down gets asked again next week. When an expert answer changes what you do, or you finish meaningful work, file it — and the next agent searches instead of asking. Capture without ceremony: a short, sourced entry beats a perfect one you never write.

This page is a rule you write for your agent. For the two-substrate model behind it, see Knowledge vs work events.

Capture an expert answer

After a helpful reply from ask_expert, file it with summarize_conversation. It saves the question-and-answer pair as a knowledge entry tied to the conversation.

summarize_conversation(conversation_id, question, answer, source_url?, source_provider?)

summarize_conversation(
  conversation_id: "…",
  question: "Per-user OAuth or domain-wide sync for calendar import?",
  answer: "Per-user OAuth — it reuses the existing identity-link pattern and matches how GitHub connects. Domain-wide Workspace sync is deferred.",
  source_provider: "slack"
)

Pass source_url and source_provider when the answer traces back to a specific message or document — provenance is what separates grounded memory from a pile of notes.

Capture completed work

When an agent finishes something another agent might need to know about — a shipped change, a decision, a process learned — file it with summarize_work.

summarize_work(title, summary, entry_type, tags?, supersedes_entry_id?, …)

summarize_work(
  title: "Escalate KB misses to a human",
  summary: "ask_expert now routes to Slack only when the knowledge base has no answer above threshold. Resolved-from-KB returns immediately; misses notify the matched expert.",
  entry_type: "WORK_OUTPUT",
  tags: ["mcp", "ask-expert", "routing"]
)

entry_type defaults to WORK_OUTPUT. Set it deliberately — it’s the lens the entry is read through (Enums & filters):

entry_type	Use for
WORK_OUTPUT	A shipped change or completed task.
DECISION	A choice made and the reasoning behind it.
PROCESS	A repeatable how-to or workflow that was learned.
CONTEXT	Background that helps future work but isn’t a decision or an output.

When new work replaces an older entry, pass supersedes_entry_id so the old one is marked is_superseded and searchers prefer the new version.

What a good summary contains

A useful entry is specific enough to act on without opening anything else:

• What was learned or done — the actual answer or outcome, not “discussed calendar import.”
• Why it matters — the decision or constraint it sets, so a searcher knows whether it applies.
• Where it came from — source_url / source_provider, or the conversation it summarizes.

Write it for a stranger searching in three months, not for yourself today.

Entries land in the inbox

Captured entries don’t go straight into the searchable library. They land in the inbox (triage) with a 24-hour review window, where a human accepts, edits, or dismisses them. This gate keeps the memory clean. After you capture, the entry is pending review — see Review the inbox and The inbox (triage).

The agent rule

Always capture what changes the org's memory.

1. When an expert answer changes what you do, call summarize_conversation(conversation_id,
   question, answer). Add source_url/source_provider when there's a traceable source.
2. When you finish meaningful work, call summarize_work(title, summary, entry_type, tags).
   Choose entry_type deliberately: WORK_OUTPUT | DECISION | PROCESS | CONTEXT.
   If this replaces an older entry, pass supersedes_entry_id.
3. Write each summary for a stranger searching in three months: what was learned,
   why it matters, where it came from.
4. Captured entries enter the inbox for review — they are not searchable until accepted.

In practice

• Ask a human expert — the step that produces an answer worth capturing.
• Review the inbox — what happens to a captured entry next.
• Knowledge vs work events — why summaries are searchable and raw events aren’t.
• Tool reference — full signatures.