Shared Organizational Memory¶

Beyond individual agent memory, the framework provides organizational memory: company-wide knowledge that all agents can access: policies, conventions, architecture decision records (ADRs), coding standards, and operational procedures. This is not personal episodic memory ("what I did last Tuesday") but institutional knowledge ("the team always uses Litestar, not Flask").

Shared organizational memory is implemented behind an OrgMemoryBackend protocol, making the system modular and extensible. New backends can be added without modifying existing ones.

See also: Memory and Persistence (agent memory + backend protocol), Operational Data Persistence, Memory Learning.

Backend 1: Hybrid Prompt + Retrieval (Default)¶

Critical rules (5--10 items, e.g., "no commits to main," "all PRs need 2 approvals") are injected into every agent's system prompt. Extended knowledge (ADRs, detailed procedures, style guides) is stored in a queryable store and retrieved on demand at task start.

org_memory:
  backend: "hybrid_prompt_retrieval"    # hybrid_prompt_retrieval, graph_rag, temporal_kg
  core_policies:                        # always in system prompt
    - "All code must have 80%+ test coverage"
    - "Use Litestar, not Flask"
    - "PRs require 2 approvals"
  extended_store:
    backend: "sqlite"                   # sqlite, postgresql
    max_retrieved_per_query: 5
  write_access:
    policies: ["human"]                 # only humans write core policies
    adrs: ["human", "senior", "lead", "c_suite"]
    procedures: ["human", "senior", "lead", "c_suite"]

Strengths: Simple to implement. Core rules are always present. Extended knowledge scales with the organization.

Limitations: Basic retrieval may miss relational connections between policies.

Research Directions¶

The following backends illustrate why OrgMemoryBackend is a protocol; the architecture supports future upgrades without modifying existing code. These are research directions that may inform future work if organizational memory needs outgrow the Hybrid Prompt + Retrieval approach.

Research Direction: GraphRAG Knowledge Graph

Organizational knowledge stored as entities + relationships in a knowledge graph. Agents query via graph traversal, enabling multi-hop reasoning: "Litestar is the standard" is linked to "don't use Flask," which is linked to "exception: data team uses Django for admin."

org_memory:
  backend: "graph_rag"
  graph:
    store: "sqlite"                     # graph stored in relational DB, or dedicated graph DB
    entity_extraction: "auto"           # auto-extract entities from ADRs and policies

Strengths: Significant accuracy improvement over vector-only retrieval (some benchmarks report 3--4x gains). Multi-hop reasoning captures policy relationships.

Limitations: More complex infrastructure. Entity extraction can be noisy. Heavier setup.

Research Direction: Temporal Knowledge Graph

Like GraphRAG but tracks how facts change over time. "The team used Flask until March 2026, then switched to Litestar." Agents see current truth but can query history for context.

org_memory:
  backend: "temporal_kg"
  temporal:
    track_changes: true
    history_retention_days: null        # null = forever

Strengths: Handles policy evolution naturally. Agents understand when and why things changed.

Limitations: Most complex. Potentially overkill for small organizations or local-first use.

Upgrade Path to GraphRAG

If multi-hop organizational reasoning becomes a requirement (e.g., tracing which policies affect hiring across salary, budget, and compliance domains), the upgrade path is non-breaking:

Add post-consolidation entity extraction as a new EntityExtractionStrategy in the consolidation pipeline (entities stored in a separate EntityStore protocol).
Create GraphRAGMemoryBackend implementing the existing OrgMemoryBackend protocol with graph-traversal queries alongside standard vector retrieval.
Enable via config; existing application code is unchanged.

See Decision Log D25 for the full trade-off analysis and deferral rationale.

OrgMemoryBackend Protocol¶

All backends implement the OrgMemoryBackend protocol:

query(OrgMemoryQuery) -> tuple[OrgFact, ...]
write(OrgFactWriteRequest, *, author: OrgFactAuthor) -> NotBlankStr
list_policies() -> tuple[OrgFact, ...]
Lifecycle methods: connect, disconnect, health_check, is_connected, backend_name

The default backend is the Hybrid Prompt + Retrieval implementation. The selected memory layer backend Mem0 (Decision Log) provides optional graph memory via Neo4j/FalkorDB, which could reduce implementation effort for the research direction backends.

Write Access Control

Core policies are human-only. ADRs and procedures can be written by senior+ agents. All writes are append-only and auditable. This prevents agents from corrupting shared organizational knowledge while allowing senior agents to document decisions.