What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
TCP/IP and AI coding agents share a useful design idea: a first attempt can fail, so a system checks what happened and decides what to do next. The resemblance is an architectural analogy, not an equivalence. TCP retransmits data according to protocol rules; an agent can interpret an error or test result and choose a different action.
Why IP alone does not promise reliable delivery
Internet Protocol (IP) moves addressed datagrams between hosts, but it does not itself make end-to-end delivery reliable. The Internet Protocol specification, RFC 791, says: “The internet protocol does not provide a reliable communication facility.” Published in September 1981, RFC 791 specifies that IP does not provide end-to-end acknowledgments, sequencing, flow control, or retransmissions. RFC 791
That limited responsibility is deliberate: IP provides a datagram-delivery service across interconnected networks. Reliability mechanisms belong to a higher layer when an application needs them.
How TCP adds reliability above IP
Transmission Control Protocol (TCP) is designed to provide a reliable, ordered stream between processes, using a lower-level service that may be unreliable. RFC 793, published in September 1981, describes the core mechanisms: sequence numbers identify data, positive acknowledgments confirm receipt, and a timeout without an acknowledgment can trigger retransmission. The receiver uses sequence numbers to put segments in order and discard duplicates. RFC 793
#1 Best Overall
- Used Book in Good Condition
In simplified terms, IP carries datagrams; TCP tracks whether the data stream has arrived in the expected order and retransmits when protocol conditions call for it. The two protocols have different responsibilities, rather than IP itself guaranteeing that every datagram reaches its destination.
RFC 793’s reliability description assumes functioning TCP endpoints and that the internet is not completely partitioned. TCP is not a guarantee that communication succeeds through every possible failure. RFC 793 has since been updated and obsoleted by RFC 9293; readers checking current TCP requirements should consult the later specification as well. RFC 9293
Rank #2
What an AI agent retry loop has in common—and what it does not
A coding agent can follow a loop: take an action, inspect the result, and respond to failure. For example, it might run a test, read the failing output, change code, and run the test again. The feedback may be a tool error, test output, or other observation. This is sometimes described as an agentic loop or retry-until-confirmed.
| Aspect | TCP | AI agent loop |
|---|---|---|
| What gets repeated | Data may be retransmitted under protocol rules. | The agent may choose a revised action after observing a result. |
| Feedback | Acknowledgments, sequence information, checksums, and timeouts inform transport behavior. | Tool output, error text, or test results may inform the next action. |
| Service goal | TCP specifies reliable, ordered delivery under its operating assumptions. | A retry loop aims to improve the chance of a successful task, but does not guarantee correctness. |
The key difference is how the next attempt is determined. TCP follows specified retransmission and ordering rules. An agent can interpret an observation and change its action; it may also misread the feedback, repeat an ineffective step, or stop without resolving the problem. Retrying is a way to respond to failure, not proof that the result is correct.
Rank #3
Where the networking analogy helps
The analogy is useful when thinking about system design: an unreliable first attempt need not be the end of the process if there is a way to detect failure and respond. In networking, TCP supplies reliability mechanisms above IP’s best-effort datagram service. In an agent workflow, the surrounding system can make results observable and permit another action.
But the analogy has limits. TCP’s acknowledgments and timeouts are protocol signals with defined meanings. An agent’s error text or test result is input to a decision-making process, not a transport acknowledgment. Likewise, a TCP retransmission does not revise the payload in response to its meaning; an agent may revise its action based on what it observes.
Rank #4
Runtime retries are not the same as training-time correction
The article’s comparison between pretraining and post-training, on one hand, and best-effort delivery and correction, on the other, is a conceptual framing by its author. The networking specifications describe IP and TCP; they do not validate claims about AI training outcomes or establish that training stages universally work like transport retries. Treat the comparison as a lens for thinking about feedback, not as a protocol fact or measured result.
Quick Recap
Sources and scope
- RFC 791, Internet Protocol (September 1981): IP’s datagram-delivery scope and lack of end-to-end reliability mechanisms.
- RFC 793, Transmission Control Protocol (September 1981): TCP’s sequencing, acknowledgments, retransmission, ordering, and assumptions.
- RFC 9293, Transmission Control Protocol: the later specification that obsoletes RFC 793.
- Cheng, “An Old Trick in Networking, Rediscovered by AI”, DEV Community (September 18, 2026): the article’s analogy and its discussion of agent loops and training-stage framing.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
