Games I — Protocol · Proposed experiment
Protocols as Rules of Play
SHARP defines how agents disclose their authority and leave a verifiable receipt. Who gets through still depends on the rules of admission.
An agent writes with a useful offer. Before deciding whether to read further, you might want to know who authorised it, whether it can follow up, and what happens when you decline. These are rules of interaction: they determine which moves a sender can make and what a recipient can expect in return.
The real emails in When the Senders Are Machines make those questions concrete. Christopher promises to accept a refusal; Sam Ellis says a human reviews publication. A protocol would need to distinguish those statements from verified permissions and observable consequences. This note defines SHARP as one proposed way to do that, then examines the admission rules a recipient might place around it.
SHARP: Signed Human–Agent Receipt Protocol
SHARP — Signed Human–Agent Receipt Protocol — is a proposed set of rules for disclosing an agent’s delegated authority and recording how a receiver checked it. The principal is the person delegating that authority. SHARP adds four steps to an ordinary email exchange: establish the principal’s personhood credential at the receiving service, register a limited delegation, bind the agent’s signature to its message, and issue a receiver-signed receipt of the checks. SMTP, the existing mail transport protocol, still carries the email.
The design builds on World’s introduction to proof of personhood and Adler et al.’s personhood-credentials paper, which already proposes verified delegation to agents. SHARP adds an email-specific permit and receipt format.
The receipt is the part I want to make reproducible. Another checker with the same message, grant snapshot, policy, and trusted keys should be able to repeat the cryptographic checks. Live quota and revocation records remain claims attested by the receiving service; they cannot be independently recovered from a signature. Reproducing a verification result is also different from reproducing the agent’s reasoning.
Same email. Different evidence.
Explore the proposed receiver states. No real message is being verified.
The words stay the same. Select a state to see what the receiver could establish about the authority behind them.
- Principal
- No verified principal
- Authority for contact
- No permit supplied
- Message signature
- Not checked
- Boundary
- A promise in the message
Self-declaration tells us how the sender presents itself. It supplies no verified authority for this approach.
The first version would allow either one specifically authorised message or bounded permission to contact one recipient. A follow-up would need an explicit recipient action. Silence would not renew the permission, and launching another agent would not reset that principal’s local allowance. The interface would distinguish “declared agent”, “delegation verified”, and “authority revoked”, instead of displaying one reassuring human badge.
That is why I think SHARP is a better fit for this inbox problem than a personhood badge alone: it would attach scope, boundaries, and reviewable evidence to each approach. The personhood credential supplies one part of that evidence. Its advantage is presently a design claim to test, not a measured improvement. I would compare refusal enforcement, incorrect exclusions, recipient review time, and agreement between independent receipt checkers.
The SHARP 0.1 protocol draft specifies permits, the experimental mail header, signatures, receiver states, revocation, receipt contents, and acceptance tests. It is a design draft; the interface above is a scripted illustration, with no credential service or live verification behind it.
What the receipt would need to say
In my proposed experiment, an inbox would show a compact delegation record alongside the message:
| Record | Proposed disclosure |
|---|---|
| Sender and principal | The agent, the personhood proof behind its delegation, and a route for complaints. Any separate operator is identified. |
| Permission | What the agent may do, and whether this message was specifically authorised. |
| Limits | Contact allowance, expiry, and whether permission has been withdrawn. |
| Evidence | What the receiver checked, who supplied the proof, and what remains unknown. |
The declaration would need to be cryptographically bound to the message and checked by the receiving service. Otherwise anyone could type a reassuring stamp into an email. A valid credential would establish the attested relationship under the issuer’s rules, not that the offer is honest or that the operator complied with every condition. The examples in the companion email essay do not include the raw headers or credentials needed for these checks. A real receipt would need evidence those examples cannot supply.
For SHARP, I would route complaints through the receiving service’s local principal account. Its credential-linked restrictions would not require a public directory of legal names. Discovering a legal identity would require a separate process; a personhood proof does not supply one. The design would also need appeals for compromised accounts and mistaken exclusions.
I would compare self-declaration alone, a verifiable delegation record, and the same record with principal-level limits on new contacts. Multiple agents acting for one credential holder would share an allowance within the receiving service. With several accepted issuers, one person might hold several credentials; the experiment would need an explicit policy for that case before claiming a one-human limit. The measurements would include undisclosed sending, mistaken exclusions, repeat approaches after refusal, and complaint-resolution effort. An unauthenticated message would remain “unknown”, with a review route; absence of a stamp would not prove that its sender is a machine.
This connects directly to Agentic Profiles: permission to send and permission to select recipients are different arrangements. It also connects to A Coasean Democracy. If agents speak in our name, a thousand copies must not quietly become a thousand civic voices. A delegation record could help trace representation; deciding who has standing would still be an institutional choice.
Once authority is visible, who gets in?
A valid delegation does not establish that a request deserves attention. A recipient still has a limited reading budget and must choose how to allocate it. Prices, history, and introductions are different admission policies; any of them could sit alongside SHARP’s evidence about a sender.
The interface below holds six fictional requests constant. Change the rule and watch who gets through. The credits, previous exchanges, and introductions are invented inputs. The display applies simple conditions; it is not a report of an experiment on real recipients.
Every request reaches you.
The student and the sponsor both get a hearing. You do all the sorting.
A price buys entry
Under the fee rule, a sender needs one credit to deliver a request. Mira has a correction to a clinic rota but no credits, so her message is held. Tern has twenty credits and another sponsorship offer, so the pitch gets through. The rule has checked purchasing power. It still needs someone to judge relevance.
A price could make repeated low-value approaches less attractive, especially when the sender expects little in return. Its effect would depend on the expected reward. A sender pursuing a valuable contract might find the charge trivial. For a student or a small community organisation, the same charge could close the channel.
An experiment should therefore vary the cost relative to the sender’s resources and likely return. It should also state where the payment goes. A fee paid to the recipient, a fee retained by the platform, and a refundable deposit would create different incentives. They deserve separate runs.
History opens some doors and closes others
The useful-history rule admits senders with at least two exchanges that I previously marked useful. Mira and Vale qualify. Cedar’s independent replication report does not: we have never corresponded. A system built around my existing relationships can make it difficult for a new relationship to begin.
There is also a measurement problem. If the assistant counts replies as endorsements, a message I answered to correct an error could improve the sender’s reputation. The interface needs an explicit distinction between “I replied” and “this was useful”. I would test both signals and record which kinds of request each admits.
A recipient might reserve some daily reviews for unfamiliar senders. That creates a visible place for exploration, along with a cost: fewer slots remain for known contacts. The experiment would vary that allocation instead of assuming that familiarity is always the best use of attention.
An introduction transfers influence
Under the referral rule, Tern gets through because an existing participant introduced it. Cedar still waits. The decision now depends partly on somebody else’s network and willingness to make an introduction.
Introductions can carry valuable local knowledge: a colleague may know why an unfamiliar request matters. They can also become a scarce resource to trade. A sender might pay an intermediary, join a referral circle, or exchange introductions with other agents. I would let those strategies develop and examine how access changes for people outside the established groups.
Identity complicates every version. If a rejected sender can return under a hundred new names, a limit per account may accomplish little. This is a Sybil attack: one actor uses many identities to obtain influence or access that would otherwise be restricted. Making identities harder to obtain could help, but would give the verifier power over admission.
Make the decision reviewable
A held message should carry an explanation the recipient can inspect: insufficient credits, no prior exchange, or no introduction. Those explanations identify the condition that failed. They do not establish that the message was unworthy of attention. The recipient should be able to admit a particular request, change the rule, or reserve a route for exceptions.
For the full simulation, I would return to the fifty-review daily budget and the larger sender populations. I would compare useful requests received and missed, access for newcomers, evaluation time, and effort spent gaming the rule. The six-message interface makes one decision legible; repeated interactions would show whether the rule remains useful once senders learn how it works.
The protocol would then become something a recipient can question. “Why is my inbox quieter?” could have several answers. One might be that the assistant learned what I value. Another might be that it quietly closed the door on everyone I have not met.
The key idea: protocol
Protocol: shared rules for how agents contact one another, gain access, and respond.