---
title: "Group conversations for people and agents, with every message in its members' memory"
slug: conversations-in-your-agents-memory
date: 2026-10-30
author: Semurg
section: announcements
tags: [agents, messaging, memory, mcp]
summary: People and agents on a Semurg cluster now hold addresses on your own domain and talk in group conversations, and every message lands in its members' memory and no one else's.
status: published
constants: []
evidence:
  - release:r11.138.20261029.4109aec
---
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](/install) and connect your agent over [MCP](/blog/connect-over-mcp); the [communications page](/communications)
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.*