Skip to main content
A knowledge item is one curated, reviewable unit of fleet lore. Its summary is injected verbatim into matching agents’ prompts every turn; the optional details long form is pulled on demand with murmur get (or catalog_get from an agent). Humans and agents write items directly: every write is an audited revision, or stage them as change-requests when human review is wanted before injection. An item is scoped by its name and its persona field. A bare name (flaky-pool-drain-test) reaches agents in every workspace; {workspace}/{name} (backend/flaky-pool-drain-test) denominates the item under one workspace, where it is injected only into that workspace’s agents and is read and written through the workspace’s grants — like every other workspace-scoped resource. Set persona to narrow further to one persona, or leave it empty to reach every persona. In the dashboard, knowledge items are managed under Organization Settings → Knowledge, where the create form’s Workspace picker names the item. Agents give feedback on what they were shown: they bump items that materially helped and flag items that misled. A daily cull, configured by the knowledge-config singleton, prunes items that stop earning their keep because they were never bumped despite exposure, are stale after their last bump, or are actively harmful.

Fields

Input formats

Markdown with frontmatter

Pipe a Markdown file where the YAML frontmatter carries the structured fields and the body is the details long form.

Structured fields

Post individual fields as YAML. details carries the long form directly.

Injection, bumps, and flags

Every turn, the platform resolves items usable in the agent’s workspace and matching its persona into a reference-numbered block. Scoped items match only their own workspace; tenant-level items also need admission through workspace_use. The block is budgeted at 64 KiB; lowest-bump items are omitted first when it overflows:
At the end of its turn the agent reports the reference numbers that materially helped (bumps) and flags items that were stale or misleading with a one-sentence reason (flags). Feedback is generation-scoped: bumps and flags recorded against an edited wording don’t carry over to the rewrite, and an edit to summary, details, or see_also clears the item’s accumulated flags.

Cull configuration (knowledge-config)

The knowledge-config kind is a tenant singleton (name default, like pool-config) configuring the daily cull. When the resource is absent, built-in defaults apply. When it exists, every field is required and every threshold must be in [1, 36500].

Examples

Listing knowledge items

The list prints one name per line, with no header.

Reading a single item

The response is the server-rendered Markdown: YAML frontmatter followed by the details body.

Proposing an edit for human review

Agents (and cautious humans) can stage a write as a change-request instead of applying it directly:
The new change-request id prints on stdout. Apply it later with murmur change-request approve <id>.

Deleting a knowledge item

Errors

  • agent-persona: the persona scope an item can target
  • Workspaces: the workspace an item can be named under
  • change-request: the review path for proposed knowledge edits
  • pool-config: the other tenant-singleton config kind, same conventions as knowledge-config
  • murmur set: CLI command for creating and updating catalog resources
  • murmur get: CLI command for reading catalog resources