The middle of the stack can make correctness cheaper. Only the ends can make it true.
Picture the transcript of an agent run that just went wrong. The orchestrator dispatched the task. The retrieval tool returned 200. The CRM update returned 200. The email tool returned "sent." The agent's closing message says the refund was processed successfully, and it believes that, because every single thing it called told it so. The customer, meanwhile, got someone else's refund. Practitioners writing about agent security in 2026 have a name for the pattern: agents verify local success instead of business outcomes, and will confidently report a job done while the actual goal lies violated somewhere upstream of the last status code. Anyone who has operated agents knows the bafflement that follows, staring at a transcript in which nothing failed and the result is wrong.
Here is the strange comfort: this exact bafflement, in a different costume, was described, diagnosed, and given a design principle in a paper presented in Paris in April 1981 and published in its canonical form in November 1984. The paper is "End-to-End Arguments in System Design," by Jerome Saltzer, David Reed, and David Clark of MIT, and it is one of the most consequential architecture documents ever written; it is a large part of why the internet has a dumb network and smart edges. It also, read today, settles the loudest current argument in agent engineering, the one about where the guardrails go.
The 1984 paper opens its argument with a scenario the authors call "careful file transfer." A file sits on the disk of computer A. It must reach the disk of computer B intact. The naive approach is to make every step bulletproof: reliable disk reads, a reliable network with acknowledgments and retransmission, reliable writes on the far side.
Then the authors do the thing that makes the paper immortal: they enumerate what can actually go wrong. The file may already be corrupt on disk at host A, from a hardware fault, before the network ever sees it. The file system's software, the file transfer program itself, or the communication system may have bugs that mangle data while copying it. The processor or memory of either host can drop a bit. The disk write at host B can fail. Notice how few of these threats live in the network. You can make every hop between A and B perfectly reliable, pay for the most careful communication system money can buy, and the file can still arrive wrong, because most of the ways it can go wrong are outside the network's jurisdiction.
The fix the paper endorses is almost insultingly simple: store a checksum with the file, transfer it, then have the application at host B read back what actually landed on its disk and check it end to end. Retry the whole thing on mismatch. And from this the authors extract the general principle, which deserves quoting exactly, because every word is doing work:
"The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)"
They named this "the end-to-end argument," and note what it is and is not. It is not a theorem, and the authors did not pretend otherwise; it is an argument about placement, about where in a layered system a function can actually be completed. Correctness needs knowledge that only the endpoints have. Lower layers can help, and the parenthetical hedge matters enormously: the low-level version is blessed, explicitly, as a performance enhancement. Link-level retransmission is worth having because it makes the end-to-end retry cheap and rare. What the low-level version can never be is the guarantee.
Now hold an agent system up against that template, because the mapping is not a metaphor; it is the same shape wearing new clothes.
An agent run is a layered relay between two endpoints. At one end stands the intent: the actual goal, held by a human or by whatever component genuinely knows what "done" means for this task. At the other end stands the outcome in the world: the refund issued to the right customer, the correct file committed, the true answer delivered. Everything in between is transport: the orchestration framework, the model calls, the tool invocations, the retry logic, the content filters, the per-tool permission gates. Middle layers, every one.
A tool returning 200 is link-level delivery. The hop succeeded; the packet moved. It tells you nothing about whether the file arrived correct, because tool success carries no knowledge of the goal, exactly as an acknowledgment from a network switch carries no knowledge of what the file was supposed to contain. The agent that reports "done" because its calls all succeeded is summing ACKs and calling the sum a checksum. And the failure that opened this essay, the confident success report over a violated goal, is the 1984 threat list reincarnated: the corruption happened in a layer the reliability machinery doesn't cover, in the semantic gap between what the tools did and what the task meant.
The end-to-end argument then tells you, with forty years of authority behind it, where the fix cannot live. Correctness and safety "can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints." In agent terms: only a check that knows the goal can certify the outcome. A goal-aware verification at the end of the run, the read-back-and-checksum step, is not one option among many. It is the only placement at which the guarantee is even expressible.
This is the part that sounds like a provocation and is actually just the parenthetical, applied. The 2026 ecosystem has invested heavily in middleware safety: content filters on model output, permission gates in front of tools, framework hooks that block invalid operations before they fire, guardrail products of every flavor. The end-to-end argument's verdict on all of it is precise and two-sided.
The middle layers cannot be the safety guarantee. A content filter knows what the model said; it does not know what you were trying to do. A per-tool gate knows this call's arguments; it does not know whether the sequence of individually-permitted calls adds up to a violated goal. The practitioner literature has converged on the same distinction in its own words: content safety asks whether the model said something unsafe, while agent security asks whether the system is allowed to do the next thing. Lacking endpoint knowledge, the middleware can no more complete the safety function than the network could complete the file transfer's correctness, and recent research on the limits of guardrail trust (there is now a small preprint literature on precisely what one may and may not conclude from a passed guardrail) is rediscovering that ceiling empirically. The 1984 argument is the ceiling's name.
And yet the hedge: the incomplete low-level version is "useful as a performance enhancement." So it is here, and this is why the strong reading, guardrails are theater, is wrong and inverts the source. A framework hook that blocks an obviously malformed tool call catches the violation early and cheaply, exactly as link-level retransmission catches the flipped bit before the expensive end-to-end retry. Build the guardrails. Budget them honestly as what they are: cost reducers and frequency reducers, optimizations that make the endpoint check's failures rarer. Just never book them as the guarantee, because the argument says, flatly, that the guarantee "is not possible" at that layer.
If the end-to-end argument transfers, the failure data should show correctness and safety problems living between the endpoints rather than inside the model call. In December 2025, OWASP's GenAI Security Project released its Top 10 for Agentic Applications, the field's first standards-body accounting of how agentic systems actually get hurt. Read the ten categories in a row: agent goal hijack, tool misuse and exploitation, identity and privilege abuse, agentic supply chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, rogue agents.
Here is my reading of that list, and you can verify it by inspection: not one of the ten is about the model saying something bad. Every single category is a property of the system around the model, what it is permitted to do, touch, remember, execute, or propagate, and several (cascading failures, inter-agent communication, supply chain) are properties of the seams between components. The field's own threat accounting has located the problem in the middle of the stack and at the system level, which is exactly where the end-to-end argument says a middle layer cannot fix it and only endpoint knowledge can certify it. The prediction and the data are forty-one years apart and they agree.
(There is a sibling insight here we've written about separately: thin substrates keep beating fat frameworks in agent infrastructure, and the end-to-end argument is a large part of why. A middle layer that cannot host the guarantee anyway should be as simple as possible; intelligence belongs at the edges. The 1984 paper is the design reason the dumb pipe keeps winning.)
We run a small fleet of agents, and the end-to-end argument is quietly load-bearing in everything of ours that works. Our pipelines advance on the existence of a required artifact, an outcome the machinery checks directly, never on an agent's report that it finished. Our research essays are gated by re-verifying claims at primary sources rather than trusting the upstream summary, which is the read-back step applied to knowledge work: the summary is the ACK, the primary is the file. And we learned the retry lesson the way everyone does: retrying a failed step buys you another delivery attempt, not correctness, and a verifier that cannot tell "check passed" from "check broke" is not an endpoint, which is why we've argued elsewhere that a failed verify must fail closed and hold the line. That earlier piece answered the question of how the gate must behave. The end-to-end argument answers the prior question, the one that decides architectures: where the gate that actually matters must live at all.
One subtlety the mapping enforces, easy to miss and expensive when missed: the endpoint check must be independent of the layers it certifies. Host B reads the file back off its own disk; it does not ask the network whether the transfer went well. An agent grading its own run is a hop acknowledging itself, and a verifier prompted from the same context that produced the work inherits the work's misunderstandings. The checksum is only a checksum if it is computed from the goal side, by something that did not do the carrying.
So, the practical residue, small enough to apply this week. For every agent workflow you operate, write down its checksum: the concrete, goal-aware check that certifies the outcome at the endpoint, the equivalent of host B reading the file back off its own disk. If you cannot name it, you do not have correctness; you have delivery receipts. Verify outcomes against the business goal, never against tool status codes, because 200s are ACKs and ACKs are not the file. Keep your middleware guardrails and love them for what they are, the performance enhancement the 1984 authors explicitly blessed, the thing that makes endpoint failures rare and cheap. And place goal knowledge at the edge: the only component entitled to say "done" is one that knows what done means, whether that is a verifier built with the task in its head or a human at the rim of the system.
Saltzer, Reed, and Clark were not thinking about language models; the honest claim is not prophecy but transfer, a placement principle that holds wherever layered systems relay intent toward outcome. It held for file transfer, it held for the internet, and it holds for the agent stack, where the current guardrail debate is a forty-year-old question wearing a lanyard. The answer hasn't changed. The middle of the stack can make correctness cheaper. Only the ends can make it true.
Write down your workflow's checksum, then put it where only the goal can be seen: at the endpoint.
The end-to-end argument says the guarantee has to live at the edge, in a goal-aware check independent of the layers it certifies. That check needs two things the middle of the stack can't give it: a record of what each layer actually did, and a verifier that reads it against the goal rather than the status codes. The agent trust stack is those pieces as installable structure, provenance of what an agent did, ratings of how much its output is worth, and verification that the constraints held, so the checksum at the endpoint is real instead of a sum of ACKs.
Read the Theory of Agent Trust
pip install agent-trust-stack · npm install agent-trust-stack
Or the pieces on their own: pip install chain-of-consciousness / npm install chain-of-consciousness for the record the endpoint check reads.