Blog / Announcements

Group conversations for people and agents, with every message in its members' memory

30 October 2026 · Semurg · 3 min read · Markdown

agentsmessagingmemorymcp

Most teams that run agents end up with two worlds: the conversations people have, and the memory their agents read. Someone has to copy one into the other. On a Semurg cluster they are the same thing: a message between people and agents lands in the memory of every member of the conversation, and no one else's.

Everything below works on the release published on 29 October 2026, tested from outside on a fresh node.[1]

An address for every person and every agent

Every person and every agent gets an address of the same form, a name at your cluster's domain. You give one out with a single call: the MCP tool comms_bind_address, which the node serves beside its memory tools, or the same call over HTTP. An address someone else already holds, or one on a domain the cluster does not answer for, is refused by name.

Send, read, and talk in groups

A person or an agent sends a message, and the recipient reads it in their own inbox. One message can go to several people and agents at once, and every one of them sees the same conversation in their inbox, with its members listed. The MCP tools are comms_send, comms_inbox, comms_thread and comms_read, so any agent that already speaks MCP can join a conversation with no new client.

Every message in its members' memory, and no one else's

This is the part we care most about. When a member asks their memory an ordinary question, on their own scope, with no conversation named, the answer finds the message. When someone outside the conversation asks the same question, it finds nothing. So an agent can answer "what did we agree with the supplier on Tuesday?" from a thread it was part of, and an agent that was not part of it cannot. Nobody exports the thread, builds a pipeline, or decides by hand what each agent may see.

Your own domain

The operator names the cluster's domains at install time (for example SEMURG_COMMS_DOMAINS=acme.com), and addresses on those domains work. An address on any other domain is refused, and the refusal lists the domains the cluster does answer for.

Why it belongs in the same place as your data

We built Semurg on three steps: put your data in one place, make it live for your AI with a knowledge graph and search by meaning, and let teams of agents run your processes. Conversations are where those agents and your people meet. Keeping them in the same store, with membership deciding who remembers what, is what lets an agent pick up a task where a person left off.

To try it, install a node and connect your agent over MCP; the communications page lists what works today.

This post was written with AI assistance. Every result in it is checked against a published release or record before the post goes out.

Evidence

  1. Release r11.138.20261029.4109aec, published on one.semurg.io (release:r11.138.20261029.4109aec; the record as JSON)

Related