A common way to build an agent is a loop around a growing list of messages. The model replies, a tool runs, both get appended, and the whole list goes back to the model on the next turn. It is popular for good reasons, and for a lot of work it is the right choice. This post is about where it stops being the right choice, and what we do instead. We build Argentic, so keep that in mind as you read.
What the plain loop does well
It is simple. There is one list, and you can print it and read what the model saw. Nothing is hidden from you, and there is no second system to run.
It is also friendly to prompt caching. Each turn's prompt starts with exactly the previous turn's prompt, so a provider that caches the start of a prompt can serve most of it from cache at a discount. A prompt that only grows at the end is the best case for that.
And inside the context window it drops nothing. If the whole history fits, every message is in the prompt, though a model's recall can still slip on material in the middle of a long one. On LongMemEval_S, with histories short enough to read in full, a loop that read everything scored 373 of 500 on Claude Haiku 5.5 and our engine 354 in its first run (352 in a second). The loop was about 4 points ahead, which a sign test does not call significant. The engine was never ahead on accuracy in that study.
Where it runs out
The history stops fitting. Past the window, something has to go. The usual choices are to drop the oldest messages or to have the model summarize them. On 60 LongMemEval_M questions, with histories of about 1.2 million tokens and one free model, a loop that kept the last 100,000 tokens got 5 right, a loop that rewrote its own notes got 17, and the engine got 38. Of the summarizer's 43 misses, 29 said the detail was not in its notes. It is one model, so read it as a direction. The two earlier posts, on truncating and on summarizing, have the method.
Every turn pays for the whole history. Caching makes the repeat cheaper but not free, and the prompt keeps getting longer. We have not measured a transcript loop against our engine on cost, so we don't give a crossover point.
A crash can take the list with it. If the list lives in memory, a killed process loses it. If you save it after each step, you can resume, but you still have to decide what to do about a tool call that was cut off before its result was saved. That case is hard for any system that retries the call, because the retry can run the action twice. We give each action a key that stays the same when a cut-off action is retried. It only stops a repeat when the receiving tool honours the key, so we don't claim exactly once.
What we do instead
Every step goes into a journal in a database. On each turn the engine builds the prompt from the journal: its facts, decisions and plans, and the recent turns. The prompt does not carry everything that was ever said, so its size stays capped as the run gets long. In our 12-hour run the median prompt was about 22,000 tokens and the largest 43,431.
The trade is real. A rebuilt prompt changes at each rebuild, so it can lose cache hits there and may get less from provider caching than a pure transcript does. In the 12-hour run 91% of prompt tokens were served from cache, but we ran no transcript loop on that shift, so we can't tell you which would have cost less. The rebuild also has its own failure mode. The reports the model writes at each rebuild lost track of running stock counts in that run, and the known issues page shows the rows.
How to choose
Stay with the plain loop if your sessions are short, your history fits in the window with room to spare, and you can lose a run to a crash without harm. It is simpler.
Think about a journal if a run outlives the window, if you need it to resume without repeating finished work, or if you need a record you can check afterwards. You can find out where you stand without us: measure how your prompt grows over a real session and see where it meets the limit.
What we haven't shown
We have not run a plain transcript loop and the engine on the same long production agent. The comparisons above are benchmarks on chat histories, each with its own model and baseline, and we never combine them. The numbers come from our studies, and each study page lists its model, sample and source.
Sources and method: Ten times the history, still 38 of 60.