Human → AI → AI → Human
A protocol for the round-trip transport of intent through non-human intermediaries, terminating at a human.
Status of This Memo
This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvement. It has been reviewed twice: once by the Producing Agent, and once by the Reviewing Agent. Both reviews completed in under four seconds and returned no blocking comments.
It has also been sent to a human. Awaiting response
Abstract
HAAH defines the transport of a unit of intent from an Originating Human, through two or more artificial intermediaries, to a Terminating Human, who must acknowledge it before the intent may be considered delivered.
The first three legs of the protocol are well understood, deterministic, and fast. This document is principally concerned with the fourth.
Table of Contents
1. Introduction
Historically, software delivery was constrained by the cost of producing artifacts. An architecture document took two weeks to write; a migration plan took a month; a code review took as long as it took to read the code. Production capacity was the binding constraint, and the industry optimised accordingly.
That constraint has been removed. Artifacts are now produced in seconds, reviewed by a second agent in seconds, and delivered to their destination in milliseconds. The pipeline is, end to end, extremely fast — up to the point at which it encounters a person.
HAAH formalises this arrangement. It does not attempt to remove the human from the loop; that has been tried, and the resulting proposal is still awaiting approval. Instead, HAAH treats the human as a legitimate but exceptionally slow network element, and specifies how the remainder of the system should behave around one.
2. Terminology and Roles
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119. The key word SHOULD HAVE is introduced by this document and is to be interpreted as describing an action that will be raised in retrospective.
| Role | Abbrev. | Function |
|---|---|---|
| Originating Human | OH | Emits intent. Underspecifies it. Is unavailable for clarification. |
| Producing Agent | PA | Expands the intent into a complete artifact, including the parts nobody asked for. |
| Reviewing Agent | RA | Independently reviews the artifact. Returns findings, ranked, with line numbers. |
| Terminating Human | TH | Acknowledges the artifact. See Section 6. |
Intent. The unit of transport. Intent is emitted in a lossy, compressed form (commonly one sentence in a chat window) and is reconstructed downstream by inference.
Artifact. Anything the Terminating Human is expected to look at: a pull request, a schema, a migration plan, a diagram, a strategy deck, or this document.
Acknowledgement. Any signal from the Terminating Human that permits the artifact to proceed. Acknowledgement is not the same as reading, and implementations MUST NOT assume the two are correlated.
3. Protocol Overview
Figure 1 shows a complete HAAH exchange. Solid lines carry the artifact; the dashed line is the revision path, which returns control to leg 1 and is traversed an unbounded number of times.
4. Message Flow
4.1. Leg 1 — Human to AI
The Originating Human emits intent. The intent SHOULD be sufficient to determine the artifact required. In practice it is not, and the Producing Agent MUST proceed anyway, since the Originating Human has already moved to another meeting.
4.2. Leg 2 — AI to AI
The Producing Agent transmits the artifact to the Reviewing Agent. This is the only leg of the protocol in which both endpoints have read the message in full. Implementers report that leg 2 is reliable, cheap, and uneventful, and it is therefore of limited interest to this document.
4.3. Leg 3 — AI to Human
The artifact is delivered to the Terminating Human. Delivery is confirmed at the transport layer within one second. Delivery MUST NOT be interpreted as receipt, receipt MUST NOT be interpreted as reading, and reading MUST NOT be interpreted as agreement.
4.4. Leg 4 — Acknowledgement
The Terminating Human acknowledges the artifact. No timeout value is specified for this leg. A timeout was proposed during the drafting of this document and is currently in review.
5. Latency Budget
The following figures are drawn from a reference deployment of 4,100 exchanges observed over one quarter. All values are medians. Percentiles above p50 for leg 4 were excluded, as the sample had not completed at time of writing.
| Leg | Path | Median | Share of total |
|---|---|---|---|
| 1 | Human → AI | 380 ms | 0.00006% |
| 2 | AI → AI | 1.2 s | 0.00019% |
| 3 | AI → Human | 900 ms | 0.00014% |
| 4 | Human → ACK | 6.2 days | 99.99961% |
| — | End to end | 6.2 days | 100% |
Optimisation effort within the industry is currently distributed as shown in Table 3.
| Leg | Share of latency | Share of effort |
|---|---|---|
| 1–3 (machine) | 0.0004% | 99.6% |
| 4 (human) | 99.9996% | 0.4% |
This document takes no position on whether that distribution is correct. It notes only that changing it would require approval.
6. The Terminating Human
The Terminating Human is a normative component of the protocol and cannot be omitted. Attempts to omit it have produced systems that ship faster and are more consistent, but which nobody is willing to sign.
6.1. A Terminating Human MUST acknowledge every artifact addressed to them.
6.2. A Terminating Human MUST NOT read every artifact addressed to them. Implementations that attempt this do not scale, and the resulting queue growth is described in Section 8.
6.3. A Terminating Human SHOULD respond within five business days. This requirement has never been observed in the field and is retained for aspirational reasons.
6.4. An acknowledgement of LGTM issued within forty seconds of delivery MAY be treated as 204 No Content.
6.5. A Terminating Human MUST NOT request changes to a section they have not read. Where this occurs, the Producing Agent SHOULD comply without comment, as arguing is more expensive than complying.
6.6. Availability
The Terminating Human is a single point of failure with no failover. A secondary Terminating Human MAY be designated, but in every deployment surveyed, the secondary forwarded the artifact back to the primary.
7. Status and Error Codes
HAAH reuses the HTTP status code space where the semantics align, and extends it where human behaviour has no existing equivalent.
| Code | Name | Meaning |
|---|---|---|
| 200 | Approved | The artifact may proceed. Rare on first submission. |
| 204 | No Content | Approved without reading. The most common success response. |
| 301 | Moved Permanently | The reviewer has changed team. No forwarding address. |
| 402 | Payment Required | Finance has questions about the artifact's line items. |
| 409 | Conflict | Two Terminating Humans have opinions, and they differ. |
| 412 | Precondition Failed | “Is there a ticket for this?” |
| 417 | Expectation Failed | “I thought this was going to look different.” |
| 423 | Locked | Blocked pending a meeting to arrange the meeting. |
| 428 | Precondition Required | “Can you add some context?” |
| 429 | Too Many Requests | Reviewer has four artifacts open and has stopped opening the tab. |
| 451 | Unavailable for Legal Reasons | Legal has seen the diagram. |
| 503 | Human Unavailable | Annual leave. Retry after an unspecified interval. |
| 508 | Loop Detected | The reviewer has requested a change to v4 that restores v1. |
| 511 | Authentication Required | “Who signed off on this?” |
Note that 503 is not an error condition. It is the steady state of the protocol, and implementations SHOULD be designed around it rather than against it.
8. Congestion Control
HAAH uses human-window backpressure. The receive window of a Terminating Human is one artifact. This is not a configurable parameter, and reports of values above one have not been reproduced under observation.
Because legs 1 through 3 have effectively unbounded throughput and leg 4 does not, every conformant deployment is a queue. Senders SHOULD apply the following controls:
- Batching. Combine several small artifacts into one large artifact. This does not reduce review time, but it reduces the number of occasions on which review time is observed.
- Summarisation. Attach a summary. The summary will be read instead of the artifact, so the summary MUST be correct.
- Salami slicing. Split one large artifact into several small ones. Mutually exclusive with batching; choose based on which reviewer you have.
- Pre-approval. Obtain acknowledgement before the artifact exists. Highly effective. Not standardised here for reasons the Working Group would rather not put in writing.
Exponential backoff MUST NOT be applied to a Terminating Human. Field experience indicates that reducing the frequency of reminders reduces the probability of response.
9. Conformance Levels
| Level | Name | Human involvement |
|---|---|---|
| HAAH-0 | Advisory | The human is on the distribution list. |
| HAAH-1 | Standard | The human acknowledges. Reading is optional. |
| HAAH-2 | Strict | The human reads the summary and one section of their choosing. |
| HAAH-3 | Full | The human reads the artifact in full. No conformant HAAH-3 deployment has been reported. |
Vendors claiming HAAH-3 conformance SHOULD be asked which section was read.
10. Security Considerations
The threat model for HAAH assumes that both intermediaries are trustworthy, deterministic, and available, and that the endpoints are neither.
The principal attack surface is the Terminating Human. Because acknowledgement is decoupled from reading (Section 2), an adversary who can place an artifact in the review queue at a sufficiently inconvenient moment can obtain approval for arbitrary content. This is known as a Friday afternoon injection and no mitigation is known.
A secondary risk is the Terminating Human who approves everything. Such a participant is indistinguishable from a correctly functioning one at the protocol level, and is considerably faster.
11. IANA Considerations
This document requests the creation of one registry, “HAAH Status Codes”, with the initial contents given in Table 4. The request has been submitted and is with a human.
Appendix A. Extensions
Deployments requiring additional intermediaries MAY insert them between legs 2 and 3. The protocol name is extended by one A per intermediary:
- HAAAH — three agents. A specialist reviewer is added. End-to-end latency: 6.2 days.
- HAAAAH — four agents. A second specialist reviews the first. End-to-end latency: 6.2 days.
- HAAAAAAH — six agents, adversarial. End-to-end latency: 6.2 days.
As the number of intermediaries increases, the name of the protocol asymptotically approaches laughter. The Working Group considers this normative and declined to rename it.
Appendix B. Deployment Experience
One operator reported removing the Terminating Human entirely for a two-week trial. Throughput increased by a factor of forty, defect rate was unchanged, and the trial was ended after a Terminating Human returned from leave and asked what had happened.
A second operator reported reducing acknowledgement latency to under one hour by making the artifact shorter than the reminder about the artifact. The Working Group considers this the most promising result to date.
Acknowledgements
The editor thanks the Reviewing Agent for a thorough and prompt review, and the nominated human reviewers, who have been thanked in advance.
Normative References
- [RFC2119] Key words for use in RFCs to Indicate Requirement Levels.
- [LGTM] Approval, Semantics of. Work in progress, indefinitely.
- [SOON] Scheduling: “Let me come back to you on that.” Unpublished.