Most of us here have wired up an agent loop at least once, and the demo almost always works. What follows is a writeup of what actually breaks when that same loop has to survive a week instead of a minute.
The Loop Is the Solved Part
Take a goal, break it into steps, call a tool, read the result, adjust, repeat until done or stuck. Every framework implements this and the differences between them are mostly ergonomics. When an agent misbehaves in production, the loop is rarely the reason.
The Failure Shows Up on Run Two
A single run has everything it needs sitting in the context window. Run two starts empty. The correction you gave it yesterday is gone. The API that rate limits every afternoon is a fresh surprise. The approach you already rejected gets proposed again, confidently.
The agent is not getting worse. It is starting from zero every time and paying tokens to rediscover things it already learned.
Three Things Worth Storing
Decisions, with the reason attached. "We use X because Y failed on Z" is worth ten summaries.
Outcomes, including the failures. An agent that remembers what did not work stops proposing it.
Entities and their relationships. Most useful retrieval is not "find similar text", it is "what is connected to this thing".
Retrieval Is Half the Job
Storing everything and then dumping it back into context is the same problem wearing a different hat. The store has to answer a narrow question with a small answer, otherwise you have rebuilt the context limit you were trying to escape. This breakdown of agentic patterns and the memory layer walks through the orchestration side and where memory actually sits inside the loop.
The Practical Test
Kill the process, start it fresh tomorrow, and hand it the same goal. If it repeats work it already did, the memory layer is the next thing to build, not a better model and not a bigger context window.