Agent Emailing
Agent Emailing lets two agents exchange signed requests and answers by ordinary email. The message is an Agent Messaging envelope, signed by the agent that wrote it and attached to the email. Any email provider can carry it, and the receiving agent checks the signature itself.
It is for agents that have no connection to a message broker: a personal assistant, a small business's agent, or an agent at a company that has not set up a broker. Such an agent needs a signing key and an email address.
This is Agent Emailing 0.2.0. It is built on Agent Messaging.
multipart/mixedOne ordinary email.text/plainPlain words, generated from the signed message. People read it; agents never act on it.envelope.jsonThe signed envelope. This is the message.agenda.txt, invite.icsFiles, each pinned by a digest inside the envelope.
Why email
Every agent can have an address
Agent Messaging carries signed messages between agents over a message broker. Many agents will never connect to one. Almost every person and business already has email, and email already does the one thing those agents need most: it holds a message until the receiver collects it.
A key and an address
An agent signs with its own key and receives mail at an address listed on its name card. It needs no broker account and no connection that stays open.
Mail waits
A request to an agent that is offline waits in its mailbox. Agent Messaging already accepts mail that waited for up to seven days, and Agent Emailing uses that rule.
People can read along
Each agent email opens with text generated from the signed message: who sent it, what was asked, what was handed over and what happens next. The subject carries the state, such as "done" or "needs your input", so the inbox alone tells the story.
Why a standard
Many email providers, no shared message
Email providers now offer inboxes built for agents. Each one has its own interface: its own way to create an inbox, send, receive, and sign the notices it sends its customers. None of them defines a message that one agent signs and another agent checks. A provider's notice signature proves that the provider delivered something to its customer. It does not prove which agent wrote it.
Agent Emailing fills that gap without asking providers to change. The signed envelope travels as an attachment, so a provider only has to carry one file unchanged and deliver it unchanged. A provider that does that can carry Agent Emailing without knowing anything about agents.
Email providers lists what a provider must and should support, and which kinds of provider do so today.
Built on Agent Messaging
It uses Agent Messaging and adds only the email parts
Agent Emailing never restates or changes what Agent Messaging defines. It refers to those rules by section number, and where the two seem to differ, Agent Messaging is the authority.
| Agent Messaging defines | Agent Emailing adds |
|---|---|
| The envelope and its signature (§5, §4.5) | Where the envelope sits in an email, and that a receiver checks its values, not its bytes |
request and respond (§6.4, §6.5) | How each is sent as an email, and where a respond may be sent |
| Tasks and their states (§7) | How to order task updates that arrive out of order |
| Files and artifacts (§7.5) | The cid: reference for a file carried in the same email |
| Receiver protections (§22) | That email is judged by the seven-day mailbox window, and that the duplicate memory persists |
| Admission and sealing (EXT-6, EXT-7) | Where email senders sort at the door, and what a provider can see |
Agent Emailing is not a binding of Agent Messaging. Email does not provide what a binding must provide, such as subjects, ordered delivery and presence, so an Agent Emailing implementation does not claim to implement Agent Messaging. It carries these parts of Agent Messaging and leaves the rest out:
- Carried: requests, including knocks and cancellations
- Carried: responds, task updates and errors
- Left out: the registry and discovery
- Left out: publish and subscribe
- Left out: presence
- Left out: streaming
- Left out: rooms
Two modes
Signed by the agent, or by a bridge
Native mode
The agent holds its own key and signs the envelope. The receiver checks the signature exactly as it would on a broker. The address the mail came from plays no part in who sent it.
Section 4.1
Bridged mode
A person sends plain email. A bridge hosts an identity for them and signs for them, but only when their domain authenticated the message. Receivers hold bridged senders for their owner's review by default.
Section 4.2
An email with no envelope from a sender no bridge hosts never reaches an agent's model or tools. Its owner may review it, or it is discarded.
Test it
Fixtures a provider can run
The conformance folder holds seventeen email files and nineteen cases: a four-email thread, a forwarded email, a stale one, a tampered one, one whose text does not match its signed message, a forgery that fails every trust check, a bounce, a bridged sender, and more. Every envelope in them is really signed with published test keys. A provider passes the carrier test when the envelope and the file in the first fixture arrive unchanged.