Long-horizon tasks require LLM agents to continually draw on information from earlier interactions. However, retaining the full history increases context costs, while compressing it risks losing details needed later, and the relevance of historical information often becomes apparent as the task progresses. To address these challenges, we propose FlowState, which treats execution state as memory that can be retained and revisited across requests, unifying current decision-making with the reuse of historical information. FlowState preserves semantically typed state nodes, their relations, and references to raw tool observations, separating persistent retention from on-demand access. Within a single execution loop, Incremental State Update (ISU) maintains the current state based on new inputs and feedback, while Progressive State Access (PSA) progressively reveals historical states and supporting evidence as needed during reasoning. Together, these mechanisms enable agents to reassess prior decisions in light of new information and guide subsequent actions. Compared with a full-context baseline using the same DeepSeek-V4-Flash model, FlowState improves the average success rate on MemoryArena and the average pass rate on $τ^3$-Bench by 4.55 and 13.95 percentage points, respectively, while reducing total token consumption by 43.2% and 40.6%. These results demonstrate the performance and efficiency advantages of FlowState on long-horizon tasks.
Sam: A cheaper hotel can still be the wrong choice. FlowState helps language-model agents revisit earlier decisions and their evidence, improving benchmark success while processing less text.
Alex: That sounds like a memory problem, but remembering more usually means reading more. What kind of work is this?
Sam: It’s a method-paper preprint by Minghao Li, Bangyan Li, and colleagues at Ant International, Ant Group. They propose saving an agent’s working state across requests, rather than repeatedly feeding it the entire conversation.
Alex: So this matters if your agent handles connected tasks, not just isolated questions. An earlier constraint might change what counts as a good answer much later.
Sam: That’s the setting: shopping, travel planning, formal reasoning, and customer-service tasks. We’ll follow one booking decision, unpack what the memory system changes, and ask how far the benchmark evidence supports it.
Alex: Start with the alternatives. If the conversation already contains the relevant information, why build another representation?
Sam: The authors describe a trade-off. Keeping the full interaction history increases context costs and can bury relevant details. Compressing that history saves space, but can discard something that becomes important later.
Alex: And storing the history outside the conversation only helps if the agent retrieves the right part. It might recover an old decision without recovering the reason behind it.
Sam: That’s the other problem the paper targets. What needs retrieving may become clear only during reasoning. A retrieved decision can point toward another constraint, which then requires checking the original evidence.
Alex: What is actually new here, compared with a compact working record plus a search tool?
Sam: The authors make execution state itself the memory unit. By execution state, they mean recorded requirements, observations, assessments, and reusable outputs. Those records retain identities and links across requests, so the agent can reopen a decision and follow its dependencies.
Alex: Make that concrete with the hotel. What does the agent need to remember beyond the original booking?
Sam: In the paper’s example, the user books hotel A for two hundred dollars. They plan to reconsider if hotel B becomes cheaper. After dealing with flights and other arrangements, they learn that B now costs one hundred sixty dollars.
Alex: The lower price alone favours switching. But the original booking might have terms that change that comparison.
Sam: It does: cancellation now costs eighty dollars. Switching would therefore cost two hundred forty dollars altogether. Keeping the original booking is cheaper, even though the alternative’s room price has fallen.
Alex: So a memory saying “reconsider if B gets cheaper” is incomplete. The agent needs the decision linked to the cancellation terms, and those terms linked to their evidence.
Sam: FlowState preserves that chain. The agent can reopen the earlier decision, follow its link to the terms, and inspect the policy observation. It then records a new decision using both the new price and the old evidence.
Alex: That example explains the desired behaviour. What keeps the system from simply loading every linked record and recreating the full-history problem?
Sam: It separates storage from visibility. Full records live in a persistent repository outside the model’s immediate input. The model sees a historical index containing identifiers and short summaries, alongside the records currently available for deciding what to do.
Alex: The index tells it what exists. Opening a record reveals its contents and relations, but not automatically everything those relations point to.
Sam: Yes, and that selective opening is called Progressive State Access. The agent can request a historical record, examine what comes back, then decide whether to follow another link. Access unfolds alongside the task rather than happening only once before reasoning starts.
Alex: What happens to the working record as new information arrives? Rewriting a summary repeatedly was one of the problems you started with.
Sam: Incremental State Update handles that part. The model proposes local additions, revisions, or removals instead of regenerating the whole state. Historical records cannot be deleted; revisions and removals apply only to records created during the current request.
Alex: There’s a timing issue here. If the agent requests evidence and chooses an action in the same model call, that action cannot depend on evidence it hasn’t received.
Sam: The paper explicitly separates those steps. Newly opened information becomes available on the next model invocation. The agent can defer action, read the disclosed evidence, and then decide; the underlying model’s parameters remain unchanged throughout.
Alex: Let’s move from the mechanism to the tests. What did the authors compare, and how broad was the evaluation?
Sam: The main comparison uses the same DeepSeek model for FlowState and the full-history baseline. They test selected MemoryArena environments covering shopping, travel, mathematics, and physics. They also test airline and retail interactions in tau-three Bench, where actions must follow business rules.
Alex: Those measure different kinds of success. What are the headline gains without mixing the outcomes together?
Sam: On MemoryArena, average success rises by about four-point-six percentage points over full history. That gain comes with roughly forty-three percent fewer total tokens, the units of text processed or generated by the model.
Alex: So it’s not merely buying better performance by feeding the model more text. Does the service-interaction benchmark show the same overall pattern?
Sam: There, average pass rate rises by about fourteen percentage points over the same-model full-history baseline. Total token use falls by roughly forty-one percent. But retail action accuracy declines, even though overall task pass rate improves.
Alex: That distinction matters: better completion doesn’t mean every measure improved. How much evidence says the linked-state design matters, rather than just having any memory system?
Sam: On MemoryArena, the authors compare against retrieval systems, the compact-state method ZipAct, and ZipAct combined with keyword retrieval. FlowState beats that direct combination on every reported task-performance measure. Simply attaching retrieval to state tracking did not produce consistent gains.
Alex: And when they remove pieces of FlowState itself, does the proposed division of labour hold up?
Sam: In the tested shopping and travel settings, replacing incremental maintenance with rule-built historical records eliminates complete task successes. Exposing all historical states instead of opening them progressively uses more tokens. That alternative does slightly better on shopping progress, but worse on complete success.
Alex: That supports complementary roles, not a claim that selective access wins every metric. What happens as tasks get deeper, when earlier information has more opportunities to go missing?
Sam: FlowState leads at every reported depth in shopping and travel. In formal reasoning, it generally leads later on, but ties the combined state-and-retrieval baseline at the final depth. Additional model comparisons also show performance and token-efficiency gains in the evaluated settings.
Alex: Where would you stop trusting the claim? Benchmark agents and deployed assistants don’t face identical consequences.
Sam: I’d treat this as promising benchmark evidence, not deployment validation. The experiments include no real users or real transactions. The authors warn that persistent memory can expose sensitive information or carry outdated and incorrect assumptions into later decisions.
Alex: So preserving evidence helps inspect a decision, but doesn’t guarantee that evidence remains valid. Who should read the full document, and where should they begin?
Sam: Researchers building agent memory or long-running tool workflows should read it. Start with Persistent Execution State and State Operations to understand what gets saved and when it becomes visible. Then read the component ablation alongside the main results, especially the distinction between progress and complete success.
Alex: And for someone who only needs the central idea?
Sam: Keeping information does not mean keeping it all in view. The useful memory is the decision you can reopen, with a path back to the evidence that could change it.
Alex: Thanks for listening.