Open a chat interface and ask it to write you a function, and you'll get an answer in a few seconds — maybe it works, maybe it doesn't. Either way, that's the end of the conversation. The moment the model hands you an answer, that is the end of the story.
Now try the same request in a coding agent like Claude Code or OpenAI's Codex. Neither just hands you a block of text and walks away. It writes the code, runs it, reads whatever error comes back, changes what's wrong, and runs it again. Only after five or ten times over that the thing actually works, does it show you the result.
Even with the same underlying model, you get dramatically different reliability. The difference has a big name: the agentic loop. And it turns out this exact trick — turning something unreliable into something reliable by trying, checking, and trying again — was invented decades before any of this existed, for a completely different technology, but for exactly the same reason.
You don't need a networking background for this, but you've probably heard the term "TCP/IP" — the pair of protocols quietly handling just about all of your everyday internet traffic. What's less well known is that they didn't start out as a pair. They were one protocol, and the reason they split apart turns out to be the missing piece of this whole story.
In 1974, Vint Cerf and Bob Kahn (both are recipients of the 2004 Turing Award) published the design for a single protocol called TCP — at the time, short for T ransmission C ontrol P rogram (not Protocol, mind you). It did everything: addressed every packet, moved it across the network, and guaranteed it arrived complete and in the right order. For the next few years, that was the entire plan. One protocol, one job: never give up until delivery was confirmed.
Then real-time applications showed up — voice, video, radar tracking — and exposed a problem nobody had designed around. These applications did not want TCP's guarantee. A phone call that s to retransmit a lost syllable is worse than one that just drops it and moves on; waiting for certainty was actively harmful when speed mattered more. But the original TCP had no setting for "fast and occasionally lossy" — full reliability was baked into every packet, non-optional.
In the spring of 1978, at a meeting at USC's Information Sciences Institute, Cerf, Jon Postel, and Danny Cohen resolved this by cutting the protocol in two. The bottom layer kept only the minimum job and got a new name: IP. Its task was just to get an addressed packet somewhere, best-effort, no promises. The top layer kept the name TCP, now much narrower: acknowledgments, retransmission, ordering — all the guarantee logic, but optional, layered on top instead of forced onto every packet. From that point on, an application could choose: use IP alone and accept some loss for speed, or add TCP on top and accept some delay for certainty.
To carry forward, we just need to remember this:
That last clause matters more than it looks. The split wasn't just an engineering cleanup — it was an admission that "guaranteed correct" and "fast" are sometimes in tension, and the right answer depends on the task. That's exactly the choice AI tools hand you today, just dressed up in words and code instead of packets.
Going to the opening example, it is easy to see the parallel.
A one-shot answer from a chat interface is a single forward pass: you ask the model a question, it gives you an answer, and that's final — right or wrong, it doesn't check itself and doesn't get a second attempt. That's IP: get something out the door, with no guarantee attached.
Claude Code or Codex working in a loop is TCP wearing different clothes. Take an action, observe what happened — did the tests pass? did the tool call error out? — and if it failed, try again (perhaps with a somewhat different approach), until it succeeds or hits a retry limit. Send, check for acknowledgment, retry on failure, give up after a timeout: same structure, just applied to code instead of packets.
What makes the comparison satisfying is that it's a fair, apples-to-apples test: run the identical prompt both ways and compare. The reliability gain from looping isn't magic — it's the exact same trick TCP uses to turn "best-effort" into "reliable."
It's worth being honest about the limits, because that's where the real texture is.
TCP's retry is dumb, in a specific sense: it resends the identical packet, and success is judged by a binary signal — a checksum either matches or it doesn't.
An agent's retry is not that. When code fails, the model reads the actual error message, reasons about why it failed, and typically tries something different the second time. The reliability-via-retries structure matches, but the intelligence level does not.
Here's the part that's easy to miss. The story so far is about how a finished model is used. But the same best-effort-then-corrected pattern also describes how the model was built in the first place.
Pretraining is the stage where large language models cram the entire corpus of internet text into their weights. When interacting with a human through a chat interface, a model does only one thing: predict the next token, one at a time. No checking. No correction. The errors we feed it also come out ready-made: deprecated API calls lingering in old GitHub repositories, Stack Overflow answers that looked plausible but were actually wishful thinking, off-by-one errors in textbook examples, mathematical ``proofs'' with sign errors, etc. A model trained on all of this simply cannot tell a buggy pattern from a correct one, as long as both show up enough often in the text. That's best-effort, IP-style: fast, with no guarantee of correctness.
Post-training is where corrections get introduced. The job is to go back and break the model out of its ruts. For coding and reasoning tasks, it works by asking the model to generate its own attempts, then checking those attempts against ground truth--Does the code pass its tests? Does the math check out?--and adjusting the model weights to narrow the gap between success and failure. Some approaches even reintroduce a dedicated critic model: a second network whose whole job is to judge whether each step in a long attempt checks out. That's the TCP mindset applied to training: take a best-effort attempt, check it, correct it, repeat.
So the connecting thread isn't a coincidence — it's the same idea, applied at two different points in time, with the bill just arriving on a different schedule.
At runtime, retries happen live: every task pays its own cost, and whatever gets corrected only applies to that one output. At training time, retries happened once, in bulk, before anything shipped: the cost was paid up front by whoever trained the model, and what got corrected was a general tendency, baked permanently into the weights. That's why a model that's been through solid post-training usually doesn't need to loop at all for tasks resembling the ones it trained on — the retrying already happened, exhaustively, in advance.
Put simply: it's less "retry until it works" and more "practice until you don't need to retry."
A couple of honest caveats, so this doesn't overclaim.
TCP/IP layers are strictly stacked — every packet passes through all four layers, every time, in the same order. Pretraining and post-training aren't like that; they're sequential, one-time training phases, not a repeating per-request pipeline.
And post-training's correction is narrower than it might sound. It works best where correctness is checkable — code that runs, mathematical proofs that checks out. However, it doesn't generally clean up factual errors or misconceptions the model absorbed from bad sources during pretraining, since there's no automatic verifier for ``is this historical claim true.'' That's a separate, harder problem, and one reason models can still confidently state incorrect facts even after heavy post-training.
Two things this raises that don't have clean answers yet.
As post-training keeps improving, will agentic loops eventually become unnecessary even for genuinely novel problems — or will there always be some category of task too new for any amount of training-time practice to have anticipated, meaning the live retry loop never fully goes away?
And is there an equivalent of UDP for AI — a deliberately no-retry, good-enough-and-fast mode, chosen on purpose for situations where speed matters more than certainty, the same way real-time voice chose plain IP over TCP? Live captioning or real-time translation might be exactly this case: a slightly wrong word now beats a perfect one two seconds late.
Network architecture figured this out decades ago: IP is honest about being unreliable, and TCP is the layer that buys back reliability through repetition and acknowledgment. AI systems are rediscovering the same trade-off at two different timescales — once permanently, during training, and once transiently, every time an agent loops at runtime. The interesting engineering question, in either domain, was never whether to pay for reliability. It's when, and how much of it you actually need.