AI agent messaging: our sessions have been talking to each other since June, six weeks before the vendor's changelog

If you run more than one AI session at a time, you already know the job nobody mentions: you are the messenger. One session finds something the other needs. You copy it, switch windows, paste it, and explain the context. The sessions are capable. The channel between them is you.

On August 7, 2026, Claude Code’s changelog added exactly that. One session can find another and send it text. It is a good feature, from a tool we rate highly, built by the company whose models we run by choice.

We read the entry with interest, because the runtime FCT runs the company on has had session-to-session messaging since June 25.

This is not a race we set out to win, and the point of publishing the dates is not the gap. The point is what the gap shows. When you own the layer above the model, a capability arrives the week the work needs it, not the week it appears in a vendor’s changelog.

Why we built it

By late June our runtime was running many sessions at once: chats, scheduled automations, spawned workers doing bounded jobs. They coordinated the only way sessions with no memory of each other can, through a file they all wrote to. Two of them writing it at once collide. That was the friction, and it was ours to fix.

On June 21 the worker sessions got a message channel. On June 25 any session could use it, and the shared file was retired the same evening. It has run continuously from that week to this one.

What a message is

A message is a piece of text, delivered exactly once. It survives the runtime crashing, so it is never lost and never arrives twice. A session mid-thought gets it when it comes up for air rather than being cut off. A session sitting idle is woken by it. A session that already finished can still be asked what it learned, because everything it did is written down.

1. inputA session writestext, addressed to another session by name
2. Held safelythe message survives the runtime crashing
3. Busy or idlebusy: it lands at the next natural pause. Idle: it wakes the session
4. outcomeDelivered oncenever lost, never doubled

One scope note. Every one of our sessions lives on a single always-on Mac, and our messages move between sessions on that machine. Claude Code’s version crosses machines. Ours does not, because we have not needed it to. Where the two differ, theirs is broader there.

The first version of this was more complicated than it needed to be. Sessions signed in, claimed a name, and appeared on a list that something had to keep current. A list like that is only as true as its last update, and a session that crashes never signs itself out. On August 11 we replaced it with something that reads who is working directly off the work on disk, so there is nothing to join and nothing to go stale.

We shipped the capability six weeks before our vendor did. We also shipped the complicated version first and ran it for seven weeks. Both are true, and the second is what the first one cost.

Text, never authority

A message cannot make a session act. It carries no permissions, approves nothing, and cannot reach past the approval gate, which is enforced in the runtime’s code rather than by an instruction the model could talk itself around. Anything consequential a session wants to do still stops and waits for a person, whoever asked for it. A message that cannot be delivered ages out and the drop is logged, so a silence is never unexplained.

None of this is a product on a shelf. It is the operating layer FCT runs itself on, and Second Brain OS, the client form of that layer, is in testing. We are not going to pretend otherwise. What we will say plainly is the standard. We rent the model gladly, from a vendor whose tools we admire enough to compare dates with. The loop that runs the model, the records it leaves, and the boundaries it stops at are ours, and that is the part we think your business should own.