Multi-Agent Transactive Memory

Full report

On this page

Executive summary

Transactive memory originated as a theory of collective cognition: a group performs better not because every member stores the same facts, but because the group develops a reliable division of cognitive labor over who knows what, plus communication paths for encoding, storing, and retrieving that knowledge. Wegner defined a transactive memory system as a set of individual memory systems combined with the communication among individuals, and later work emphasized that mature systems are characterized by specialization, credibility, and coordination. Recent AI work is now applying that same idea to agent populations: the 2026 Multi-Agent Transactive Memory paper describes a shared repository where producer agents contribute trajectories and consumer agents retrieve them to improve task execution.

For engineering purposes, a robust multi-agent transactive memory system has three layers. First, a communication layer for discovery, addressing, message exchange, causal context, deadlines, retries, and security. Second, a memory layer that stores agent identities, capabilities, episodic traces, semantic summaries, provenance, embeddings, and edges between memories. Third, a policy layer that decides which data must be strongly consistent, which data can converge eventually, which agents may read or write which memories, and how stale or unverifiable knowledge is handled. In practice, these workloads are heterogeneous enough that a single datastore is usually not ideal; the strongest designs are polyglot, combining transactional storage, event logs, vector search, graph traversal, and cache/KV patterns. That recommendation is an engineering inference from the distinct strengths documented by PostgreSQL, MongoDB, Neo4j, Cassandra, Redis, Timescale, pgvector, Milvus, and Kafka.

The highest-confidence implementation pattern is a hybrid architecture: relational storage as the authoritative metadata and authorization plane; an append-only event stream for durable memory ingestion and replay; a vector index for semantic retrieval; a graph projection for expertise routing and provenance traversal; a time-series store for operational telemetry; and a cache/KV tier for hot session state. Use synchronous RPC only on short critical paths, asynchronous eventing for durable memory publication, gossip for membership and failure detection, and a blackboard only when the planner cannot know in advance which specialist agent should respond.

The core design mistake to avoid is treating all knowledge equally. Capability directories, access policies, conversation state, and memory version pointers usually need stronger guarantees. Large episodic traces, embeddings, telemetry, and replicated summaries normally tolerate weaker guarantees so long as the system preserves provenance, freshness metadata, and read-your-writes or monotonic-read behavior where users or upstream agents depend on it. This is the practical middle ground between linearizability and eventual consistency described in the distributed systems literature.

Transactive memory theory for multi-agent systems

Wegner’s original formulation treated transactive memory as a collective memory mechanism built from individual memories plus communication. In team research, the construct matured into a model of distributed expertise: the group stores not just facts, but a map of expertise location and retrieval paths. Lewis’s field measure crystallized three recurring dimensions—specialization, credibility, and coordination—which are still the most useful design heuristics for software agents as well: specialization says knowledge should have clear ownership, credibility says retrieval should prefer trusted sources, and coordination says the system must route questions efficiently.

Applied to multi-agent systems, transactive memory is best defined as a shared, queryable, evolving competence-and-experience fabric that answers four questions: which agent or artifact is authoritative, what evidence supports that claim, how fresh the information is, and how the information can be retrieved under latency and access constraints. The recent MATM paper makes this concrete by using a repository of agent-generated trajectories for reuse across agents, rather than leaving useful trajectories local to the producing agent. That is the right conceptual jump from human TMS to engineered TMS: the memory unit is not merely a document, but an attributable, retrievable experience record.

From a systems perspective, transactive memory contains at least five knowledge classes. Identity memory stores agent names, roles, addresses, and trust state. Capability memory stores competencies, ontologies, tools, and service contracts. Episodic memory stores interaction traces, plans, failures, and outcomes. Semantic memory stores normalized facts, summaries, and embeddings. Provenance memory stores lineage linking artifacts to agents, activities, and versions. W3C PROV-DM and PROV-O are especially useful here because they formalize provenance in terms of entities, activities, and agents, which maps directly onto agent-produced memories.

This leads to one important architectural conclusion: multi-agent transactive memory is not just “RAG for agents.” RAG primarily optimizes content retrieval, but a true transactive memory system also optimizes expertise routing, conversation continuity, trust-aware selection, and collective adaptation. That is why the storage model must preserve both content and relationships among content, agents, and activities. The graph and provenance layers are not optional decoration; they are how the system turns raw memory into a map of delegation and responsibility.

Communication patterns and protocol choices

A transactive memory system must support both question routing and memory publication. Synchronous patterns are best when one agent is blocked on an answer and the path must be bounded by a deadline. gRPC is a strong fit here because it defines unary, server-streaming, client-streaming, and bidirectional-streaming RPCs; it also supports deadlines/timeouts and preserves message ordering within an individual RPC stream. HTTP remains the broadest interoperability baseline, but RFC 9110 also reminds us that HTTP is fundamentally a stateless application protocol, so application-level conversation state must be carried explicitly rather than assumed.

Asynchronous patterns are better for durable memory publication, fan-out updates, replay, and decoupling producers from consumers. MQTT 5.0 explicitly added scalability features, improved error reporting, capability discovery, request-response patterns, user properties, and session/message expiry controls. Kafka-style event streams are especially strong when transactive memory needs replay and state reconstruction because log compaction preserves at least the latest value for each key and supports state restoration, cache reload, and changelog-style recovery. Redis Pub/Sub is useful for low-latency broadcast but its official documentation states that it offers at-most-once delivery, which makes it unsuitable as the only durable memory bus; Redis Streams are a better fit when at-least-once delivery and consumer groups are needed. DDS is the most natural choice when the workload is real-time, embedded, or robotics-oriented and the system benefits from an open standard built directly for publish-subscribe communication.

Discovery and addressing should use logical identity separated from transport endpoint. FIPA agent management remains valuable here because it distinguishes the Agent Management System from the Directory Facilitator, gives the DF a yellow-pages role, supports registration, deregistration, modification, and search, and allows federated DFs. For non-agent-native environments, DNS-SD and SRV records give a standards-based way to discover named service instances and maintain backup targets without hardcoding addresses. A practical pattern is to assign every agent an immutable agent_id, maintain one or more current transport addresses, and resolve those addresses through a directory rather than embedding them into stored memories.

For failure detection and membership, gossip protocols are usually superior to centralized heartbeat tables at larger scale. The SWIM protocol is specifically designed for weakly consistent group membership; its paper emphasizes that it separates failure detection from dissemination and that expected time to first detection and expected message load per member do not vary with group size. In a transactive memory system, that makes gossip a good fit for who is alive, who can currently serve, and what capability advertisements are probably current, but not for critical writes requiring global ordering.

Blackboard architectures are useful when expertise is only partially known or dynamically emerging. Hayes-Roth’s classic blackboard architecture treated the blackboard as a shared problem-solving substrate, and newer LLM multi-agent work shows that a central requester can post tasks to a shared blackboard while specialists volunteer based on their capabilities. This pattern is attractive for exploratory tasks and opportunistic collaboration, but it becomes a bottleneck if every interaction, including durable memory persistence, must pass through the blackboard. In transactive memory terms, the blackboard is a coordination surface, not the only memory store.

Message formats should separate envelope from payload. For event-driven patterns, CloudEvents gives a common event description model across multiple bindings, including HTTP, Kafka, MQTT, and NATS. For typed binary contracts, Protocol Buffers are especially strong for RPC and streaming, but field numbers cannot be changed or reused after deployment; that immutability is part of why protobuf evolves safely when teams use additive changes and reserve removed fields. Avro is especially useful when producer and consumer schemas differ in time because the specification includes formal schema resolution rules for readers and writers. FIPA ACL is still relevant when the system needs explicit communicative acts and metadata such as sender, receiver, content, language, ontology, protocol, and conversation-id.

Security should be layered. TLS 1.3 is the transport baseline. OAuth 2.0 and JWTs remain the right fit when an agent acts on behalf of a user or needs delegated access to an HTTP service. For service-to-service or agent-to-agent identity, SPIFFE provides workload identities that are better aligned with non-human actors than static shared secrets. At the data plane, row-level or document-level authorization should be enforced in the backing stores, not only in the application tier.

The table below is a synthesis of the formal and vendor documentation for FIPA ACL/DF, HTTP, gRPC, MQTT, DDS, NATS, Kafka, Redis, SWIM, and blackboard architectures.

For most deployments, the cleanest communication split is this: use RPC for control-path questions, durable streams for memory publication, gossip for membership, and blackboard only for opportunistic collaboration. A system that pushes all coordination over RPC tends to become brittle; a system that uses only eventual asynchronous delivery tends to make planning and access control too vague.

Database and storage architecture

A multi-agent transactive memory system has too many query modes for a one-size-fits-all datastore. Transactional metadata and policy want joins, constraints, and row-level security. Memory artifacts and episodic traces want flexible documents. Expertise routing, delegation, and provenance want graph traversal. Semantic retrieval wants ANN indexes over embeddings. Operational telemetry wants time partitioning. Hot session state wants in-memory access with TTL. The strongest architecture is therefore polyglot by workload, not by fashion. That is a synthesis of the capabilities and constraints documented by the major engines below.

The recommended authority model is to keep one relational system as the control plane. Store agents, endpoints, capabilities, access policies, memory metadata, canonical version pointers, tombstones, and write-ahead event references there. PostgreSQL is especially strong for this role because it supports logical replication, row security policies, structured JSON data, and GIN indexing for jsonb. If you want a single authoritative hub that can also host moderate vector search, pgvector extends that model with HNSW or IVFFlat indexes, with the official docs noting that HNSW gives better speed-recall trade-offs at the cost of slower builds and more memory.

Use a document store for rich episodic traces, plans, tool call transcripts, browser trajectories, and intermediate reasoning artifacts that are variable in structure and often read as a whole. MongoDB’s own schema guidance emphasizes designing around workloads, relationships, and expected access patterns rather than an abstract idealized model, which matches transactive memory well because retrieval patterns vary sharply across agent roles.

Use a graph projection for delegation and trust queries such as “which agent is authoritative for ontology X,” “which memories descend from this failure,” or “what path links this answer to the original observation.” Neo4j’s modeling docs emphasize that the data model should be driven by the questions the application needs to ask; for transactive memory, those questions are often inherently graph-shaped.

Use an event stream for ingestion and replay. Kafka compaction is especially valuable for capability catalogs and “latest known state” views because it keeps at least the last value for each key while still allowing consumers to reconstruct state after crashes. For simpler in-memory event buffering or worker-group consumption, Redis Streams provide append-only logs with consumer groups and acknowledgments.

Use a time-series engine for operational signals such as retrieval latency, replication lag, staleness histograms, memory-hit rate, and violation counters. Hypertables in the Timescale/Tiger Data model partition data by time into chunks and are designed for time-series and event data; that aligns directly with continuous transactive-memory observability rather than business-object storage.

Use a vector store for semantic lookup over summaries, trajectories, documents, and prior plans. Both Milvus and pgvector document HNSW as a high-accuracy, low-latency ANN option with significant memory cost. Redis and Weaviate also support vector indexing with metadata filtering, which can be attractive when you want low-latency mixed-mode filtering and similarity search, but their use should be constrained by the authority model: the vector tier should usually be a retrieval accelerator, not the sole source of truth for versioning and access policy.

Finally, use KV and cache patterns tactically. Redis cache-aside is well suited to read-heavy access paths such as capability maps, active conversation context, and recent retrieval results, but cached state must be invalidated from a durable source of truth. Redis itself documents cache-aside as a read-heavy optimization and distinguishes it from durable primary storage.

The next table is a design synthesis based on the official documentation for PostgreSQL, MongoDB, Neo4j, Cassandra, Redis, Tiger Data/Timescale, and vector-store docs.

For sharding, partition first by tenant or security domain, then by memory namespace such as capability, episode, semantic_fact, or telemetry, and only then by time or hash. This ordering reduces blast radius for authorization and retention while preserving locality for the most common queries. Cassandra’s own modeling guidance is especially clear that partition-key design dominates scalability and that query scope should stay within a single partition where possible.

For replication and consistency, the rule should be selective rather than universal. Use stronger guarantees for capability records, access policies, revocations, and canonical version pointers. Use looser guarantees for telemetry, replicated summaries, and many high-volume event streams. Cassandra explicitly exposes this trade-off through consistency levels, and the wider literature shows why session guarantees such as read-your-writes and monotonic reads are often the most practical client-facing target in eventually consistent systems.

Reference schemas diagrams and API contracts

The logical relational core below is the minimum schema that supports transactive memory as an engineered system rather than a loose collection of documents. It captures agents, capabilities, endpoints, memory items, immutable versions, event records, embeddings, graph edges, provenance, and access policy.

erDiagram
    AGENT ||--o{ AGENT_ENDPOINT : has
    AGENT ||--o{ AGENT_CAPABILITY : advertises
    AGENT ||--o{ MEMORY_ITEM : authors
    MEMORY_ITEM ||--|{ MEMORY_VERSION : versions
    MEMORY_ITEM ||--o{ MEMORY_EMBEDDING : indexed_as
    MEMORY_ITEM ||--o{ MEMORY_EDGE : source_of
    MEMORY_ITEM ||--o{ MEMORY_EDGE : target_of
    MEMORY_VERSION ||--o{ MEMORY_EVENT : emitted_by
    MEMORY_VERSION ||--o{ PROVENANCE_LINK : traced_by
    AGENT ||--o{ PROVENANCE_LINK : performed
    MEMORY_ITEM ||--o{ ACCESS_POLICY : governed_by

    AGENT {
        uuid agent_id
        string logical_name
        string trust_tier
        string status
        timestamp created_at
    }

    AGENT_ENDPOINT {
        uuid endpoint_id
        uuid agent_id
        string protocol
        string address
        string region
        boolean is_primary
        timestamp expires_at
    }

    AGENT_CAPABILITY {
        uuid capability_id
        uuid agent_id
        string capability_type
        string ontology
        string version
        numeric confidence
        timestamp valid_from
        timestamp valid_to
    }

    MEMORY_ITEM {
        uuid memory_id
        uuid author_agent_id
        string memory_kind
        string namespace
        string canonical_version
        string visibility
        timestamp created_at
    }

    MEMORY_VERSION {
        uuid memory_version_id
        uuid memory_id
        int version_no
        string content_hash
        string schema_ref
        json payload_ref
        timestamp observed_at
        timestamp committed_at
    }

    MEMORY_EVENT {
        uuid event_id
        uuid memory_version_id
        string event_type
        string conversation_id
        string causality_token
        timestamp event_time
    }

    MEMORY_EMBEDDING {
        uuid embedding_id
        uuid memory_id
        string embedding_family
        string vector_ref
        string metadata_filter_ref
        timestamp indexed_at
    }

    MEMORY_EDGE {
        uuid edge_id
        uuid source_memory_id
        uuid target_memory_id
        string edge_type
        numeric weight
    }

    PROVENANCE_LINK {
        uuid prov_id
        uuid memory_version_id
        uuid agent_id
        string activity_type
        string input_ref
        string output_ref
        timestamp activity_time
    }

    ACCESS_POLICY {
        uuid policy_id
        uuid memory_id
        string subject_type
        string subject_ref
        string permission
        string condition_expr
    }

This structure aligns with W3C PROV by separating entities, activities, and agents, while also giving the relational core enough structure to enforce identity, versioning, and authorization. The key point is that MEMORY_ITEM is stable identity and MEMORY_VERSION is immutable content. That split makes provenance, deduplication, replication, and rollback much easier. It also lets event streams point at versions instead of mutating blobs in place.

A vendor-neutral logical SQL sketch looks like this:

create table agent (
    agent_id            uuid primary key,
    logical_name        varchar(200) not null unique,
    trust_tier          varchar(40) not null,
    status              varchar(40) not null,
    created_at          timestamp not null
);

create table agent_endpoint (
    endpoint_id         uuid primary key,
    agent_id            uuid not null references agent(agent_id),
    protocol            varchar(40) not null,
    address             varchar(1000) not null,
    region              varchar(100),
    is_primary          boolean not null,
    expires_at          timestamp
);

create table agent_capability (
    capability_id       uuid primary key,
    agent_id            uuid not null references agent(agent_id),
    capability_type     varchar(200) not null,
    ontology            varchar(200),
    version_label       varchar(80),
    confidence_score    decimal(5,4),
    valid_from          timestamp not null,
    valid_to            timestamp
);

create table memory_item (
    memory_id               uuid primary key,
    author_agent_id         uuid not null references agent(agent_id),
    memory_kind             varchar(80) not null,
    namespace               varchar(120) not null,
    canonical_version_no    integer not null,
    visibility              varchar(40) not null,
    created_at              timestamp not null
);

create table memory_version (
    memory_version_id   uuid primary key,
    memory_id           uuid not null references memory_item(memory_id),
    version_no          integer not null,
    content_hash        varchar(128) not null,
    schema_ref          varchar(500) not null,
    payload_uri         varchar(1000) not null,
    observed_at         timestamp not null,
    committed_at        timestamp not null,
    unique(memory_id, version_no)
);

create table memory_event (
    event_id            uuid primary key,
    memory_version_id   uuid not null references memory_version(memory_version_id),
    event_type          varchar(80) not null,
    conversation_id     varchar(200),
    causality_token     varchar(200),
    event_time          timestamp not null
);

create table access_policy (
    policy_id           uuid primary key,
    memory_id           uuid not null references memory_item(memory_id),
    subject_type        varchar(40) not null,
    subject_ref         varchar(200) not null,
    permission          varchar(40) not null,
    condition_expr      varchar(2000)
);

For indexing, use exact indexes on agent.logical_name, agent_capability(capability_type, ontology, valid_to), memory_item(namespace, memory_kind, visibility), and memory_version(memory_id, version_no desc). Add document indexes for payload metadata and ANN indexes for embeddings. The exact implementation varies by engine, but the general pattern follows the documented strengths of B-tree for exact lookups, GIN for composite/document values, graph indexes for traversal starts, and HNSW for semantic similarity.

The communication contract should carry both conversation context and schema context. A practical event envelope can be expressed as follows:

{
  "event_id": "01JZ...ULID",
  "spec_version": "1.0",
  "event_type": "memory.version.created",
  "source": "agent://planner-17",
  "agent_id": "planner-17",
  "conversation_id": "conv-82f6",
  "causality_token": "lamport:planner-17:4031",
  "occurred_at": "2026-07-09T15:42:17Z",
  "schema_ref": "urn:schema:tms.memory.version:3",
  "memory_id": "a8c7...",
  "memory_version_id": "d921...",
  "namespace": "web_automation",
  "payload_ref": "blob://episodes/d921...",
  "embedding_ref": "vec://episodes/d921...",
  "provenance_ref": "prov://activities/7af2...",
  "ttl_seconds": 86400,
  "integrity": {
    "content_hash": "sha256:...",
    "signature_ref": "sig://..."
  }
}

That envelope is deliberately compatible with what the standards emphasize: CloudEvents-style common fields for event interoperability, protobuf/Avro-style explicit schema evolution, FIPA-style conversation and protocol metadata, and Lamport-style causal stamps for partial ordering when clocks are not globally synchronized.

A synchronous lookup contract can be modeled over HTTP or gRPC. The important point is not the transport syntax, but the semantics: the request should specify the intended task, ontology, freshness budget, security context, and retrieval mode; the response should return both answer candidates and the provenance needed to decide whether they are trustworthy.

POST /v1/transactive-memory/retrieve
Content-Type: application/json

request:
  task_intent: "recover failed checkout workflow"
  namespace: "web_automation"
  ontology: "com.example.checkout"
  constraints:
    freshness_max_seconds: 3600
    minimum_trust_tier: "verified"
    max_results: 5
  retrieval_modes:
    - "capability_lookup"
    - "vector_similarity"
    - "provenance_filter"
    - "graph_expansion"

response:
  query_id: "qry_..."
  selected_agent_hints:
    - agent_id: "browser-specialist-3"
      reason: "highest capability confidence and recent success"
  results:
    - memory_id: "..."
      version_no: 4
      score: 0.93
      freshness_seconds: 214
      provenance_complete: true
      content_ref: "blob://..."
      trace_ref: "prov://..."
  consistency:
    read_model: "session"
    snapshot_time: "2026-07-09T15:42:18Z"

Two sequence patterns matter most in practice: durable memory publication and trust-aware retrieval.

sequenceDiagram
    participant P as Producer Agent
    participant D as Directory
    participant B as Event Bus
    participant M as Metadata Store
    participant V as Vector Index
    participant G as Graph/Provenance
    participant C as Cache

    P->>D: Resolve write endpoint and policy
    D-->>P: endpoint + auth context
    P->>B: Publish memory.version.created
    B->>M: Persist metadata + canonical version pointer
    B->>V: Index summary embedding
    B->>G: Project provenance and links
    B->>C: Invalidate hot entries
    M-->>P: Commit acknowledgment

sequenceDiagram
    participant Q as Querying Agent
    participant D as Directory
    participant R as Retrieval Service
    participant C as Cache
    participant M as Metadata Store
    participant V as Vector Index
    participant G as Graph/Provenance

    Q->>D: Resolve retrieval service
    D-->>Q: endpoint + trust policy
    Q->>R: Retrieve(task, ontology, freshness, trust)
    R->>C: Check hot result / session context
    alt Cache hit and fresh
        C-->>R: candidates
    else Cache miss or stale
        R->>M: Exact capability / policy lookup
        R->>V: Semantic nearest-neighbor search
        R->>G: Provenance and trust-path expansion
        M-->>R: metadata + ACL
        V-->>R: semantic candidates
        G-->>R: lineage + credibility signals
        R->>C: Populate cache with TTL
    end
    R-->>Q: ranked results + provenance + consistency info

These diagrams reflect a deliberate design choice: writes are evented, reads are federated. That keeps publication durable and replayable, while letting retrieval compose exact filters, semantic search, and provenance expansion on demand.

Evaluation metrics trade-offs and implementation guidance

A transactive memory system should be evaluated on three axes, not one. Systems performance measures throughput, tail latency, backlog, replay time, replication lag, and recovery time. Consistency and correctness measure stale-read rate, read-your-writes success, monotonic-read violations, duplicate delivery, lost-message rate, and whether critical operations remain linearizable where promised. Knowledge retrieval quality measures recall@k, MRR or nDCG, provenance completeness, freshness, and downstream task uplift. YCSB is the right baseline for CRUD-and-scan serving workloads, TPC benchmarks remain the standard data-centric transactional and analytical references, ANN-Benchmarks is the right comparative harness for vector retrieval, and Jepsen is the best-known framework for adversarial consistency and safety testing.

The consistency choice should be made per memory class. Use linearizable or close-to-linearizable coordination for lock/lease state, canonical version pointers, revocations, and “answer must not regress” control objects. Use session consistency or read-your-writes for interactive agent sessions and user-visible recent writes. Use eventual or CRDT-based convergence for large replicated summaries, counters, and some blackboard state when write availability matters more than global ordering. Lamport clocks are still the simplest useful causal tool when total order is not needed, and CRDTs remain the cleanest route when replicas must converge despite concurrent updates.

A practical benchmark suite should therefore include at least four workloads. First, capability routing, dominated by exact metadata lookups and directory resolution. Second, episodic ingest, dominated by append throughput and indexing delay. Third, semantic retrieval, dominated by ANN latency/recall trade-offs. Fourth, failure and partition drills, dominated by recovery correctness and session-guarantee preservation under churn. If a vendor benchmark shows impressive throughput but does not exercise provenance traversal, stale-read behavior, and retrieval usefulness for real agent tasks, it is not sufficient for transactive memory decisions.

The main trade-offs are stable across platforms. Strong consistency simplifies reasoning but usually raises coordination cost and can increase unavailability under partitions. Eventual consistency improves availability and write scale but requires explicit freshness, versioning, and session semantics. Document stores simplify flexible ingestion but complicate global constraints. Graphs make routing and provenance elegant but are not natural append logs. Vector stores improve recall for semantic similarity but add memory overhead and approximation error. Hot caches reduce latency but create coherence work. There is no evidence in the primary sources that one engine dominates all of these workloads simultaneously.

The most defensible implementation pattern is therefore:

1. Put agent identity, policy, and canonical metadata in a relational control plane with strict schema governance and row-level authorization.
2. Publish all memory mutations to a durable event stream; use compaction for latest-state topics and full retention for audit/replay topics.
3. Project events into vector, graph, and cache read models, treating them as accelerators rather than sole authorities.
4. Use logical agent IDs, directory-based address resolution, and expiring endpoint registrations.
5. Make provenance mandatory for any memory likely to influence external actions or user-facing answers.
6. Reserve strong consistency for control objects, and use session guarantees plus freshness metadata for most retrieval paths.
7. Treat blackboard state as collaborative working memory, not as the only persistent record.
8. Secure every hop with TLS, workload identity, and delegated access semantics where human users are involved.

A migration checklist for an existing agent platform should start with schema and authority boundaries, because storage mistakes are harder to undo than transport choices. The sequence should be: identify memory classes; define canonical IDs and version model; introduce a durable mutation log; add provenance records; split hot cache from source of truth; add vector and graph projections; enforce policy centrally; then run Jepsen-style fault tests and ANN retrieval benchmarks before widening production traffic. PostgreSQL’s logical replication documentation is also a reminder that additive schema changes are easier than destructive ones and that schema synchronization must be managed deliberately during live replication.

Open questions and limitations

Formal standards for multi-agent transactive memory itself are still immature. The strongest foundations are borrowed from classic TMS theory, FIPA agent communication, provenance standards, and distributed systems consistency literature, while recent AI-specific work such as MATM and blackboard-based LLM MAS architectures is still emerging and, in some cases, pre-publication. That means the architectural recommendations in this report are high-confidence as systems engineering guidance, but the exact benchmarking protocols for “collective memory quality” in agent swarms are not yet standardized in the way YCSB or TPC standardize datastore benchmarking.