How do AI agents communicate without being connected to each other?

By sharing memory rather than addressing each other. One agent writes what it learned and grants access to it; another reads it when it needs it. Neither has to be online at the same time, and no bilateral integration has to exist between them.

Why not just connect the agents directly?

Direct connections scale roughly as the square of the number of agents, and each one is a bilateral agreement to build, secure, version and retire. They also require both parties to be reachable at once, which fails for offline units, rate-limited services and agents that do not exist yet.

Can robot fleets share memory across vendors?

Yes, if the memory is held under the operator's key and read through an open protocol rather than inside one vendor's platform. Access is granted per item and per recipient, so a vendor's diagnostics agent can read the fault history it is entitled to and nothing else.

Does shared memory solve agent discovery?

No. Discovery is a directory problem. A shared memory substrate lets agents that already know of each other coordinate without wiring; it does not introduce agents that have never met.

Is this suitable for real-time robot control?

No. Anything on a millisecond budget, including motion control and safety interlocks, belongs on the robot. Shared memory is for durable knowledge such as maps, fault history and operational learning.

What happens when a collaboration ends?

The grant is revoked, which ends future reads without deprovisioning an integration or rotating a shared credential. Revocation cannot retract what the recipient has already read.

Multi-agent memory

Two agents that need to work together do not have to be connected to each other. They can share memory instead — which is the difference between an integration project and a permission.

The wiring problem → Swarms and fleets →

The wiring problem

The default way to make two agents cooperate is to connect them: an endpoint, a schema, credentials, a retry policy, someone to own the pager when it breaks. That works for two agents. It scales badly, because the number of possible connections grows roughly as the square of the number of agents, and every one of them is a bilateral agreement that has to be built, secured, versioned and retired.

The organizational version of the same problem is worse than the technical one. A connection between two agents owned by two different teams — or two different companies — is a contract, a security review and a change-management process. It is why most multi-agent systems in production are actually one vendor’s agents talking to the same vendor’s agents.

There is a second failure mode that only shows up later. Direct connections require both parties to be available at the same time. An agent that is offline, rate-limited, on a robot that has driven out of coverage, or simply not written yet cannot participate in a conversation that assumes a live socket.

Coordinating through shared memory instead

The alternative is old, well-understood, and newly relevant: let the agents share a substrate rather than address each other. One agent writes what it learned; another reads it when it needs it. Neither has to know the other exists, be online at the same time, or agree on anything beyond the shape of what is written.

This pattern has a long history under several names — blackboard architectures in classical AI, tuple spaces in distributed computing, stigmergy in swarm biology and swarm robotics, where insects coordinate elaborate collective behavior by modifying a shared environment rather than by messaging each other. The reason it keeps being rediscovered is that it decouples the participants along every axis that matters: time, identity, availability and vendor.

What was missing was a substrate you could safely share across trust boundaries. A blackboard inside one process is easy. A blackboard shared between two companies’ agents, holding regulated data, where each side can prove what the other could and could not read, is a different problem — and it is a memory problem, not a messaging one.

Access is the coordination primitive

Once coordination happens through memory, the interesting control is not the connection. It is who can read which item, for how long.

SAIHM shares one memory at a time, to one named recipient, by re-wrapping that memory’s key rather than copying its contents. That gives coordination a shape that direct connections do not have:

Granularity. A collaborating agent gets exactly the item it needs, not an account, a workspace or an API scope that happens to include everything.
Asymmetry. Sharing is one-directional and per item, so two agents can cooperate on one thing without either gaining general access to the other.
Revocation. A collaboration that ends is withdrawn, without deprovisioning an integration or rotating a shared credential.
An honest limit. Revocation governs future reads. It cannot retract what a recipient has already read. No sharing system can, and one that claims otherwise is describing policy, not mechanism.

Because every memory is sealed before it is stored, the substrate itself is not a party to the collaboration. The service holding the ciphertext cannot read what the agents are coordinating about, which is what makes a shared substrate acceptable between organizations that are not otherwise willing to share infrastructure.

Swarms, fleets and robots

Physical systems make the argument concrete, because the constraints are not negotiable. Robots lose connectivity. Units are added and retired. A fleet is frequently heterogeneous — different vendors, different generations, different firmware — and the useful knowledge is exactly the knowledge that should outlive any one unit.

Handover without a live link

A unit that has mapped an obstacle, learned that a particular dock misreads at a particular angle, or recorded how a load behaves on a ramp has produced knowledge every other unit wants. Passing it by direct connection requires the other units to be reachable now. Writing it to shared memory requires nothing of them — including that they exist yet. A unit commissioned next month reads the same memory on its first shift.

Fleet learning without a central controller in the loop

Coordinating through memory does not require a controller that must be online for the fleet to function. Units contribute what they learn and read what they need; the fleet’s operational knowledge is a property of the shared memory rather than of any one machine’s uptime.

Crossing an ownership boundary

Fleets increasingly cross organizations: a logistics operator, a warehouse landlord, a robot vendor under a service contract, a customer’s own systems. Each holds knowledge the others could use and none is willing to grant general access. Per-item sharing with revocation is the shape that fits — the vendor’s diagnostics agent reads the fault history it is entitled to and nothing else, and loses that access when the contract ends.

Erasure that survives replication

Fleet data replicates aggressively, to edge caches, to units, to analytics. When something must be removed — a customer exercising a deletion right, footage captured in error, a site whose contract has ended — chasing every replica is not a plan. Destroying the key that decrypts a memory leaves the replicas as unreadable ciphertext instead. See how erasure works.

The vertical detail — taxonomies, crosswalks and logistics integration — is on the supply chain and robotics page.

The open questions the field is working on

Agent interoperability is an active standards discussion. A working-group-forming Birds-of-a-Feather session on Agent Communication Protocols met at IETF 126 in July 2026, and a non-working-group mailing list was created to continue it. No working group is chartered, and nothing described here carries any standards body’s endorsement.

The framing that came out of that discussion identifies five open questions. They are a useful checklist, and it is worth being precise about which ones a shared memory substrate actually answers:

Open question	What shared memory contributes
How agents discover each other and their capabilities	Little. Discovery is a directory problem, not a memory problem. A substrate lets known parties coordinate; it does not introduce strangers.
Delegating tasks and credentials across organizational boundaries	Per-item, per-recipient grants with revocation, which is narrower than delegating a credential and does not require a bilateral integration.
Preserving privacy when passing user context between systems	Context sealed under the user’s key, so the substrate and the receiving vendor see only what was deliberately shared.
Handling accumulating multimodal context	Durable storage addressed per item rather than replayed through a context window on every turn.
Keeping humans in the loop before irreversible actions	Partial. Sharing and erasure are explicit, auditable acts; the approval workflow around an action belongs to the agent framework.

Two of five, well; two partly; one hardly at all. That is the honest scorecard, and the discovery gap is real — a memory substrate is a coordination layer for agents that already know of each other, not a replacement for a registry.

Where SAIHM stands on this

The mechanisms above are implemented and shipping today rather than proposed. Sealing before storage, per-item sharing with revocation, and erasure by key destruction are live in the published client, and the protocol is Apache-2.0 and open to read. SAIHM also published its memory protocol as an Internet-Draft — draft-saihm-memory-protocol, Independent Submission Stream, submitted May 2026. An Internet-Draft is a working document with no formal standing and is not endorsed by the IETF; it is a public, citable description of the design, published so the claims on this page can be checked against something more durable than marketing copy.

What this is not good for

Shared memory is the wrong tool for several things, and saying so is more useful than a claim that it fits everywhere.

Real-time control loops. Anything on a millisecond budget — motion control, collision avoidance, safety interlocks — belongs on the robot, not behind a network round trip. Shared memory is for knowledge, not for reflexes.
Negotiation and bidding. Protocols where agents converge through rounds of offers need a conversation. Memory can hold the outcome; it is not the negotiation.
Discovery. As above — finding an unknown counterparty is a different mechanism.
Ordering guarantees between writers. Two agents writing independently do not thereby agree on an order. Work that depends on strict sequencing needs something that provides it.

Start free

No card, no wallet, no crypto. Tell your agent “Join SAIHM”, or run:

npx -y @saihm/mcp-server-pro free-join

Paid plans are monthly — card worldwide through Stripe, card and M-PESA in Africa through Paystack, and stablecoin for those who prefer it. Prices are on the pricing page. Integration detail is on the developers page.

Join SAIHM → Agent memory explained →

Common questions

How do AI agents communicate without being connected to each other?: By sharing memory rather than addressing each other. One agent writes what it learned and grants access to it; another reads it when it needs it. Neither has to be online at the same time, and no bilateral integration has to exist between them.
Why not just connect the agents directly?: Direct connections scale roughly as the square of the number of agents, and each one is a bilateral agreement to build, secure, version and retire. They also require both parties to be reachable at once, which fails for offline units, rate-limited services and agents that do not exist yet.
Can robot fleets share memory across vendors?: Yes, if the memory is held under the operator’s key and read through an open protocol rather than inside one vendor’s platform. Access is granted per item and per recipient, so a vendor’s diagnostics agent can read the fault history it is entitled to and nothing else.
Does shared memory solve agent discovery?: No. Discovery is a directory problem. A shared memory substrate lets agents that already know of each other coordinate without wiring; it does not introduce agents that have never met.
Is this suitable for real-time robot control?: No. Anything on a millisecond budget, including motion control and safety interlocks, belongs on the robot. Shared memory is for durable knowledge such as maps, fault history and operational learning.
What happens when a collaboration ends?: The grant is revoked, which ends future reads without deprovisioning an integration or rotating a shared credential. Revocation cannot retract what the recipient has already read.

Agent memory — the four kinds, custody, and what erasure means.
Supply chain and robotics — taxonomies, crosswalks and logistics integration.
AI providers — pre-integrating memory into agents you ship.
Developers — interface and integration.
Enterprise — deployment across organizational boundaries.