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 a teammate’s 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 a teammate’s 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, entry_type?, 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 entry_type when you know what the answer is — PROCESS for a repeatable how-to (write the answer as steps), DECISION for a choice and its reasoning (the default). 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.

Questions asked through Haly in Slack need no capture call: each teammate reply is written into one knowledge entry for the ask automatically, typed PROCESS when it describes how something is done, authored by the teammate and linked to the thread. See routing.

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 teammate.",
  entry_type: "WORK_OUTPUT",
  tags: ["mcp", "routing", "team"]
)

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, runbook, or convention a reader can follow again. The steps you took this session are WORK_OUTPUT.
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 a teammate 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 teammate — 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.