End-to-End Arguments in System Design

Jerome Saltzer, David Reed and David Clark at MIT wrote down a design argument that engineers had used for years without naming it. It is about where to put a function in a layered system: in the communication subsystem, in the application, or both.

The argument: if a function can be completely and correctly implemented only with the knowledge and help of the application at the end points, then providing it in the communication system is not possible. The application has to implement it anyway. A lower-layer version may still be useful, but only as a performance enhancement.

Their main example is careful file transfer from host A to host B. Things can go wrong everywhere: the disk at A returns bad data, software copying buffers makes a mistake, a processor or memory glitches, the network drops or corrupts or duplicates packets, either host crashes partway. Making the network perfectly reliable fixes only one of these. The approach that covers all of them is end-to-end check and retry: B reads the file back from its own disk, computes a checksum, sends it to A, and A compares it with the original's; only if they match is the transfer committed. Since that check is needed anyway, extra network reliability only reduces how often the end-to-end retry is needed.

A real case at MIT made the point. A network of gateways checksummed each hop. One gateway had a fault that swapped a byte pair about once per million bytes while copying between buffers, where no checksum looked. Operating-system source files were corrupted, and their owners had to compare them against old printouts.

The same reasoning applies to delivery acknowledgements (what matters is whether the target acted, not whether the message arrived), encryption, duplicate suppression, message ordering and transactions. The authors close with a caution: the argument is a guideline, and one must identify the ends correctly.

Every agent that takes real actions sits in a layered system: model, tool-calling framework, APIs, queues, databases. The end-to-end argument tells you where the checks have to live.

"The API returned 200" is a delivery receipt, not "I did it". An agent that books, pays or updates a record needs confirmation from the system of record that the action took effect: query it back and compare.

Retries create duplicates only the application can recognize. A network or queue that promises exactly-once delivery cannot stop the agent from retrying after a lost reply. Idempotency keys and request IDs belong in the application.

Guardrails in lower layers are performance aids. Schema validation in the framework, retries in the SDK and filters in the model all reduce failure rates. None of them can replace a check against what the user actually wanted, done where that intent is known.

Identify the ends before choosing. A live voice agent should drop late audio rather than wait for retransmission; a transcription pipeline should get every byte. Same data, different ends, different rules.