An Old Trick in Networking, Rediscovered by AI

Cheng — Fri, 18 Sep 2026 08:11:46 +0000

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, makes some changes, and runs it again. Only after five or ten rounds -- when it finally works -- does it show you the result.

Even with the same underlying model, reliability differs dramatically. The difference has a fancy name: the agentic loop.

But 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.

One protocol, then two: how IP and TCP came to be

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 Transmission Control Program (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.

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 pauses 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, applications 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:

IP is one-shot best-effort delivery with no guarantee.
TCP adds, on top of that, reliability by retry-until-confirmed.

The two exist as separate layers specifically so you can choose which one you actually need.

That last clause matters more than it looks. The split wasn't just an engineering cleanup — it was saying 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.

The same trick, dressed differently

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, no checking, no second attempt. That's IP: get something out the door, with no guarantee attached.

Claude Code or Codex working in a loop, however, 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.

So the reliability gain from looping isn't magic -- it's the exact same trick TCP uses to turn "best-effort" into "reliable."

Where the analogy strains

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.

This idea shows up twice

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. The model works by doing only one thing: predict the next token and try to make it match what the Internet says it should be. No double-checking of any sort. 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.

Same principle, two timescales

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, the cost of retries is paid up front by whoever trained the model, and what gets corrected is 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 no longer needs to "retry until it works" because it has practiced so many similar problems that it can just read the answer off the top of its head.

Where the whole analogy runs out

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.

A couple of open questions

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 type of task too new for any amount of training-time practice to have anticipated, meaning the live retry loop never fully goes away?

Another question. 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.

The takeaway

Reliability in a complex system is never free -- it's always bought with retries somewhere.

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.

DEV Community: Cheng