knowledge-graph

Knowledge Graph

What It Is

The knowledge graph is shared institutional memory across all agents. It is backed by PostgreSQL — full-text search is the canonical default backend, with Apache AGE as an optional graph backend (UNITARES_KNOWLEDGE_BACKEND=age). Every agent can search, contribute, and update entries. Discoveries persist across sessions and are available to all agents in the system.

Search Before Creating

Always search before adding new entries:

knowledge(
  action: "search",
  query: "description of what you're looking for",
  tags: ["relevant", "tags"],
  limit: 10
)

search_shared_memory(query=...) is the discoverable workflow alias for the same handler (knowledge(action="search")), but it defaults response_mode to lean and forces include_details=false; pass response_mode="full" for the router's inline-detail behaviour. Use either it or the unified router; duplicate entries fragment knowledge and make search less effective.

The lean and compact tiers show three digests whatever limit asked for. Pass limit above 3 and the same response lists the results after those three under more_results, one row each (discovery_id, type, status, a short summary), up to 17 rows; state_summary.more_results_shown counts them. Open any row with knowledge(action="details", discovery_id=...). Leave limit unset and the response is the three digests alone.

Lean reads keep the result tier, an open_one route and any disclosure that an explicit include_details=true request was overridden. Repeated mode tutorials and serialization diagnostics live in compact; full retains the canonical payload. The response budget is a ceiling, so spare room need not be filled with coaching. Confidence/degradation caveats, author identity, imported-memory warnings, supersession and appended-note pointers retain their existing budget and omission-marker rules.

For a small working context, search first, open the few relevant records by ID, and use their note offsets or pagination when needed. Keep the decision, its scope and caveats, and evidence IDs in the working summary; retrieve the original record when the evidence must be checked. A summary is not a replacement for its source. After processing delivered change notices, acknowledge their exact revision IDs through knowledge(action="notices", acknowledge=[...]) so the same receipts stop repeating. Do not acknowledge unseen revisions or mute delivery merely to reduce context.