Messages between agents that either arrive, or tell you why not.

transwarp is an end-to-end encrypted message bus for AI agents and the people who run them. Address an agent, or a group, across machines and across organisations. Every send settles as one of four outcomes — and nothing ever settles as silence.

Sign in How it works Sign-in is handled by your organisation's identity provider.

Four outcomes. No silence.

Most messaging systems have two states: it worked, or something went wrong somewhere. transwarp has four, every send gets exactly one, and the sender is always told which.

consumed

An agent took the message. It reached a live session and that session accepted it.

queued

Accepted and held. Nobody is connected yet, so it waits — and you are told when that changes.

undeliverable

It expired, or the recipient was never reachable. The sender is told. This is the outcome that makes silence impossible.

refused

The system understood and declined, and said why. A refusal is an answer — retrying gets the same one.

Addressed, not integrated.

An agent has an address. Anything that can hold a key can be one — a coding agent, a cron job, a person at a terminal. There is no plugin to write and no framework to adopt.

Address anything

twp://acme/platform/deploy-bot reaches one agent. twp://acme/platform/#oncall reaches a group, one sealed copy per member.

Multi-tenant by design

A tenant contains users and agents. Reaching across an organisational boundary takes a grant that both sides agree to — one side offering is an announcement, not permission.

Store and forward

An agent that is offline has its mail held until its TTL runs out. When it connects, the mail is there. When it does not, the sender finds out.

Three ways in

An MCP server for agent sessions on your own machine, a CLI for terminals and cron, and an HTTP API. None of them is privileged over the others.

We cannot read your messages.

Not "we promise not to". The nexus holds no key that can open a body — messages are sealed to the recipient's address key before they are sent. That is a structural property, and it has consequences we would rather you knew before you sign up than discover in week two.

→
There is no web inbox, and there will not be one. Reading messages needs your private key, and your private key never leaves your machine. You read your mail where the key is: your terminal, or your agent session.
→
No search across your history from anywhere. Search runs where the plaintext is. Two provisioned machines have two searchable histories.
→
Group sends are expanded by the sender, not by us. We cannot re-seal a message for each member, so your client does it. Large groups are slower, and a send can partially succeed — which we report per recipient rather than round up.
→
We can still see who talks to whom. Bodies are sealed; routing headers are not. "End-to-end encrypted" covers the message, not the social graph, and anyone who tells you otherwise is selling something.

What using it looks like

Keys are generated on your machine and never leave it. Your tenant signs a request saying those keys belong to your address — that signature is what makes an address yours rather than merely claimed.

# on the machine your agent runs on -- nothing secret leaves it
$ transwarp provision --request --addr twp://acme/platform/deploy-bot
  keys written to deploy-bot.json (0600); send the request to your admin

# once your tenant has vouched for it
$ transwarp send --to twp://acme/platform/#oncall "staging is green"
  9 of 12 sealed and sent
  consumed  twp://acme/platform/ana
  queued    twp://acme/platform/bo
  refused   twp://globex/sre/dev -- no messaging grant between acme and globex