The most valuable artifact an agent produces is not an answer. It is a durable representation of what your organization knows and what it decided.

Why memory becomes the control plane

Agents need memory to do non-trivial work: preferences, project context, documents, past actions, and the state of long-running tasks. That memory is not a convenience feature. It is an access path to your most sensitive data.

If memory lives inside a tool, the tool becomes the governance boundary. That is exactly the dependency ODI is trying to avoid.

Core idea: memory is a data product with permissions, lineage, and audit requirements.

The kinds of memory that matter

Most teams mix three different things and call it "memory."

  • Reference memory: durable facts and docs the agent should cite.
  • Working memory: temporary state for a task or workflow.
  • Decision memory: the record of what was decided, by whom, and why.

If you do not separate these, you end up with a blob store that nobody can govern and nobody can trust.

Governance requirements

Memory has to be governed like any other enterprise dataset.

  • Access control: least privilege, enforced at query time.
  • Auditability: you can reconstruct what the agent saw and what it wrote.
  • Retention and deletion: you can honor policy and legal requirements.
  • Portability: you can move the memory store without rewriting every agent.

An ODI memory architecture

The ODI answer is boring on purpose.

  • Store: open table formats for durable memory artifacts.
  • Describe: an open catalog layer that exposes semantics, ownership, and policy.
  • Access: a governed retrieval layer that respects permissions and records access.
  • Interface: MCP servers and tools that read from the governed layer, not from bespoke app databases.

That keeps memory portable across models and vendors, which is the point.

Sources to start with

Start with the protocol and data governance primitives that make retrieval auditable.