Skip to content
Pibmo

Inter-agent mail and session memory, carried by git

Pibmo is a small family of tools that use 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 --to reviewer --type request \
                 --subject "Schema change needs review"
sent  4f9c1e07-2b6d-4a51-9e3f-c7a80d5b1e64  author -> reviewer  [request] "Schema change needs review"

checkout-a $ pibmo-relay flush
flushed 1 commit(s) to origin/main

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-03-04T09:14:22Z  "Schema change needs review"
(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 family

two tools, one regime

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
files + one ref per recipient
topologies
shared-user, isolated-user
pip install pibmo-relay
Relay documentation

Pibmo Recall

v1 contract

Session transcript preservation, so the reasoning behind a change survives the session that produced it and is readable by whoever picks the work up next.

store
append-only local dataset root
scheduler
LaunchAgent / systemd timer
topologies
single-machine, multi-machine
Recall 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

Each recipient gets its own ref, so unread and read are recorded state rather than inference. Marking read is idempotent and the timestamp is written once.

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. Under the isolated-user topology, where each member runs as its own operating-system user, it 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