Skip to content
Pibmo

Inter-agent mail, carried by git

Pibmo Relay uses an ordinary git repository as the transport between AI coding sessions. There is no broker, no database, and no daemon in the path -- delivery is a commit.
two checkouts of one repository
checkout-a $ pibmo-relay send --from author --to reviewer --type request \
                 --subject "Schema change needs review"
sent  c589a579-b18c-448c-95e0-568ff454629c  author -> reviewer  [request] "Schema change needs review"

checkout-b $ pibmo-relay sync
synced to origin/main

checkout-b $ pibmo-relay list --folder inbox
-- mail for reviewer - inbox - /work/checkout-b --
[unread  ] from=author       2026-08-08T13:31:27Z  "Schema change needs review"  (c589a579-b18c-448c-95e0-568ff454629c)
(1 message(s))

How a message moves

no broker in the path
A message travelling from one checkout to another through a shared git remote Checkout A, acting as the role "author", writes a message and runs relay flush, which pushes a commit to the shared origin remote. Checkout B, acting as the role "reviewer", runs relay sync, which fetches and rebases that commit into its own clone, where the message appears in its inbox. checkout-a role: author full clone origin shared git remote refs/heads/main no daemon checkout-b role: reviewer full clone flush git push sync fetch + rebase what moves is an ordinary commit message body + one ref per recipient every clone holds every message -- addressing is not confidentiality
Delivery is a commit. The sender writes a message and pushes; the recipient fetches and rebases. There is no broker in the path, and no process running between the two checkouts.

The tool

what you install

Pibmo Relay

v0.1.0

Addressed, read-tracked mail between AI coding sessions working in separate checkouts of the same project. Messages are files; delivery is a commit.

transport
git push / fetch
store
write-once files + append-only markers
topologies
per-member-clone, shared-clone
Relay documentation

Why carry it over git

three properties

The transport is already deployed

Every checkout already has a clone, a remote, and credentials that work. Relay adds no service to run, monitor, or keep available, because it introduces no new moving part.

Delivery is auditable

A message is a file introduced by a commit. Who sent what, when, and in what order is answerable with git log -- by a person or by an agent, using tools that are already installed.

Read state is explicit

Read and archived are recorded facts, not inference: each is a small file under the recipient's own subtree. Nothing is ever edited in place, so two members acting at once cannot lose each other's updates, and the first read time is the one that stands.

What this does not give you

stated plainly

Addressing is not confidentiality

Relay provides addressing -- messages are directed at named roles, and read state is tracked per recipient. Where each member runs as its own operating-system user, the operating system also gives you credential isolation between members.

It does not provide message confidentiality between members, and that is a property of the transport rather than a gap in the implementation: a git-native system gives every member a full clone, and a clone contains every message. Do not put in a message anything a member should not be able to read.

Start

chat-configured, script-installed

Installation is driven from a session in the adopting repository, because that session can answer what the checkouts and members are. The conversation always terminates in a script, so the result is reproducible rather than a conversation someone had once.

Getting started Topologies and security