Blog

Context layer for AI agents: one record, many agents

Aperisa ยท 7 min read

OpenClaw and Hermes Agent both keep each agent's memory separate by default. That's the right call for isolation, and it's also how two of your agents end up quoting different payment terms for the same client.

A context layer for AI agents fixes that by giving the whole loop one shared, read-only record of facts that all your agents query, with sources attached to the facts it returns. Memory stays per agent, for how each one works. Facts live in one place. Our view: in a multi-agent loop, agents shouldn't remember business facts at all. They should look them up in the same record and cite where they found them.

Why do agents in a multi-agent loop drift apart?

Because per-agent memory is the default, and it's a sensible default.

In OpenClaw, per the multi-agent docs, each agent gets its own workspace, its own agent directory with auth profiles, and its own session store. Built-in memory search covers only that agent's memory and its own sessions. It doesn't search another agent's transcripts. Agents can still reach each other's sessions through the agent-to-agent tools, which are on by default, but that's messaging, not a shared record.

In Hermes Agent, you run a second agent as a second profile. The profiles docs describe a profile as a separate Hermes home with its own config, API keys, memory, sessions and skills.

Now run that for a month. Here's a made-up timeline:

  • Week 1: you tell your ops agent the Northwind contract is net 30. It saves that.
  • Week 2: a signed amendment changes it to net 45. Your research agent reads the email while summarizing your inbox and saves "Northwind: net 45."
  • Week 3: the ops agent drafts a payment reminder using net 30. The research agent, asked the same question in Slack, says net 45.

Neither agent is broken. Each remembered correctly, from a different week. Neither one can show you which version is current, because a memory entry carries no source. Multiply that by every client, date and amount your agents touch, and you get a loop that argues with itself.

Why shared memory for AI agents usually isn't the fix

The obvious answer is to let the agents share one memory. The harness docs push back on that, at least for writable memory.

The Hermes memory docs say: "Don't point two agent processes at the same Hermes home directory." Their reason is the clearest description of the problem we've seen: "two writers sharing one home will compound each other's entries into state neither of them (nor you) authored."

OpenClaw gives you a middle path. Several agents can index the same Markdown through an explicit memory.search.extraPaths directory. That's useful for shared notes and conventions. It still leaves the same question open: who writes those notes, and how do they get updated when the contract changes?

Shared writable memory turns drift between agents into drift inside one store. The fix is to separate two things that usually get lumped together:

Agent memory Context layer
Scope One agent All agents in the loop
Written by The agent Built from your documents and accounts
Agent access Read and write Read only
Holds Preferences, conventions, what happened Amounts, dates, terms, contacts
Evidence None The email or document each fact came from

What should a context database for AI agents look like?

Three properties matter more than the storage engine.

Read-only to agents. Agents query it. They don't write to it. Facts change when the documents change, not when an agent decides something.

Built from the originals. If the record comes from the signed amendment rather than from a chat, the net 30 versus net 45 question has one answer.

Sourced. A fact comes back with the email or document behind it. That's what lets an agent, or you, settle a disagreement in one click.

Exposing it as an MCP tool is the practical route, because both harnesses already speak it. The rest of this post is three patterns we'd use with any such record.

Pattern 1: one source of truth that all your agents query

Connect the same read-only server to each agent and allowlist only its read tools. With a made-up server, in OpenClaw per the OpenClaw MCP docs:

openclaw mcp add records \
  --url https://records.example.com/mcp \
  --transport streamable-http \
  --include 'search_records,get_document'
openclaw mcp doctor records --probe

The docs make a point worth keeping: "Saving a definition proves nothing about reachability," so run the probe.

In Hermes, the same made-up server goes in each profile's config.yaml under mcp_servers, per the Hermes MCP docs:

mcp_servers:
  records:
    url: "https://records.example.com/mcp"
    tools:
      include: [search_records, get_document]

Then give every agent the same rule in its memory or context file: "For amounts, dates, terms and contacts, query records and cite the document. If memory and the record disagree, use the record and say so."

Memory still does its job. The ops agent remembers that you want reminders sent on Mondays. It just stops being the place where net 30 lives.

Pattern 2: give each agent its own key, with placeholders for public channels

Most multi-agent loops include at least one agent that talks in public: a Slack channel with guests, a Telegram group, a Discord server. That agent needs to know the shape of your data without carrying the real details into a channel where other people read the replies.

The pattern is a separate credential per agent. Give each agent its own key, and set the key for any public-facing agent to return placeholders instead of real details. If an agent misbehaves or a token leaks, you revoke that one key without touching the others.

A note on scope, because this is where context layer products differ. Some systems let you limit an agent to part of the data. A key per agent doesn't do that by itself. Check what your record actually enforces before you rely on it.

Pattern 3: agents cite sources to each other

In a loop, facts move between agents as messages. That's where drift spreads fastest. A fact passed along without a source becomes the next agent's memory.

So make the source part of the handoff. A made-up message from a research agent to an ops agent:

Northwind payment terms: net 45.
Source: Amendment 2 to the MSA, section 6, signed 2026-09-12 (Drive).
Supersedes: net 30 in the original MSA.

The receiving agent can check it, and so can you. Add a rule to your orchestrator: a fact without a source is a claim, not a fact, and it gets looked up before anyone acts on it.

Frameworks that coordinate agents through messages make this easy to enforce. cortextOS, an open-source multi-agent system, has orchestrator, analyst and specialist agents that coordinate through a shared file bus. Any setup like that can carry a source line in the message body, and an orchestrator can refuse handoffs without one.

Where does Aperisa fit?

Aperisa is one example of a shared record of facts. It reads Gmail, Drive, Calendar and Contacts with read-only Google access, plus the bank accounts you link, and keeps a searchable copy to answer from. It maps those records into one structured record and serves it through a read-only remote MCP server with no send, write or delete tools. It looks up your records instead of asking a model to recall them, and answers come with the email or document they came from.

Give each agent its own key and set what it can reach: which data areas, work or personal, and how much detail, from full records down to totals only. Aperisa enforces those limits on the server. Revoke a key and it stops working within 2 minutes.

One record, many agents

Per-agent memory is right for how each agent works, and wrong as the home for facts the whole loop depends on. Keep memory separate. Share one read-only, sourced record, and make agents pass the source along when they hand a fact to each other.

Aperisa connects as a remote MCP server over Streamable HTTP with a Bearer key, and each key can be limited by data area and level of detail. Try it out.

FAQ

What is a context layer for AI agents? In a multi-agent setup, it's a shared source of facts that all your agents query, separate from each agent's own memory. A useful one is read-only, built from your documents, and returns the source with each fact it gives back.

Should multiple agents share one memory? Usually not as a writable store. The Hermes docs warn that two writers sharing one home "will compound each other's entries into state neither of them (nor you) authored." Keep memory per agent and share a read-only record of facts instead.

How do I stop agents in a multi-agent loop from disagreeing about facts? Point them all at one read-only source of facts that they query as a tool, have them pass the source along when they hand a fact to another agent, and tell them to prefer the record over their own memory when the two conflict.

Can a shared context layer limit what each agent sees? Some systems scope data per agent, and Aperisa does it per key. Give each agent its own key and set what it can reach: which data areas, work or personal, and how much detail, from full records down to totals only. Aperisa enforces those limits on the server. Revoke a key and it stops working within 2 minutes.

Sources

Questions

What is a context layer for AI agents?

In a multi-agent setup, it's a shared source of facts that all your agents query, separate from each agent's own memory. A useful one is read-only, built from your documents, and returns the source with each fact it gives back.

Should multiple agents share one memory?

Usually not as a writable store. The Hermes docs warn that two writers sharing one home "will compound each other's entries into state neither of them (nor you) authored." Keep memory per agent and share a read-only record of facts instead.

How do I stop agents in a multi-agent loop from disagreeing about facts?

Point them all at one read-only source of facts that they query as a tool, have them pass the source along when they hand a fact to another agent, and tell them to prefer the record over their own memory when the two conflict.

Can a shared context layer limit what each agent sees?

Some systems scope data per agent, and Aperisa does it per key. Give each agent its own key and set what it can reach: which data areas, work or personal, and how much detail, from full records down to totals only. Aperisa enforces those limits on the server. Revoke a key and it stops working within 2 minutes.

Published

Keep reading