LoongFlow: A Plan-Execute-Summary Loop Framework With Structured Experiential Memory

The Problem LoongFlow Targets: Long-Range Iteration, Not Single-Shot Prompting

Most agent frameworks are built around a single request. You give the model a task, it calls tools, it returns an answer. That shape works for retrieval, for summarisation, for code completion. It does not work when the task is a search over a large space of candidate solutions, where each attempt teaches you something and the next attempt should be better than the last. LoongFlow is aimed squarely at that second category. The README describes it as an expert-grade Agent development framework, and the phrase it repeats is long-range complex reasoning. The intended user is a developer who already has domain knowledge and wants to encode it into an agent that improves across iterations rather than one that answers once. The README names three shipped agents as the concrete entry points: General-Agent for coding tasks, Math-Agent for mathematical algorithm design, and ML-Agent for machine learning construction. Each lives in its own directory under agents/ in the repository. That layout tells you something about the design intent. The framework is not a single general runtime with plugins bolted on. It is a core loop plus three reference implementations that show what the loop looks like when it is pointed at a specific domain.

The PES Loop and What Happens Between Planning and Summary

The mechanism LoongFlow is built on is called PES: Planning, Execution, Summary. The README describes it as a paradigm that gives agents structured thinking for long-range tasks, and contrasts it with agents that iterate without structure. The three phases map onto a cycle. Planning produces an approach for the current round. Execution carries that approach out, which in the shipped agents means producing a candidate solution or a candidate algorithm. Summary reflects on the result and writes down what was learned. The output of Summary is what feeds the next Planning phase. That is the loop. The second half of the mechanism is the memory. LoongFlow uses what the README calls Multi-Structure Fusion Memory, and describes it as actively generating model reasoning contexts so the agent can synthesize experience during task iterations. The README frames the result as a run-and-improve mechanism, and states explicitly that this is achieved without heavy retraining. That distinction matters. The framework is not fine-tuning anything. It is accumulating context across iterations and re-injecting it. If you have worked with evolutionary search, the shape will be familiar: generate candidates, evaluate them, keep what worked, use it to bias the next generation. LoongFlow's contribution, as described, is doing that with an LLM in the loop rather than with mutation operators alone. The repository topics list evolutionary-algorithms, genetic-algorithm and iterative-refinement alongside the agent topics, which is consistent with that reading. The README also lists openevolve-alternative as a topic, so the authors position it against evolutionary search tooling rather than against general agent runtimes.

Getting It Running: Python 3.12, the agents Directory, and the PyPI Package

The installation surface is small, and the README does not hide it behind a wrapper. The Python badge in the README specifies python-3.12+, so the interpreter floor is 3.12 and there is no indication of support for 3.11 or earlier. The project publishes to PyPI under the name LoongFlow, which is the package name to install. The README links a Quick Start section for the commands themselves; the material available here does not reproduce the exact pip invocation or the CLI entry point, so check that section before you assume a command name. What is visible is the structure you will be working inside. There are three agent directories, agents/math_agent, agents/ml_agent and agents/general_agent, each with its own linked README in the repository. That is where the per-agent configuration lives: the task definition, the evaluation criteria, and whatever model or tool settings the agent needs. The framework itself is the loop and the memory; the agent directory is the domain. If you are evaluating LoongFlow, the fastest way to judge it is to read the math_agent or ml_agent README rather than the top-level one, because the top-level README explains the paradigm and the agent READMEs explain what you actually have to supply. The homepage points to arXiv paper 2512.24077, which is the reference for the claims the README makes about the paradigm. The README also links a GitHub Discussions page, which is the stated channel for questions.

Where LoongFlow Is the Wrong Tool

The most important limitation is not stated as a limitation, but it follows from the design. A loop that plans, executes, summarises and remembers only improves if there is a signal telling it whether the last round was better than the one before. In the ML-Agent and Math-Agent cases that signal is inherent: a model has an accuracy, an algorithm has a runtime. In a general coding task, that signal is much harder to define, and the General-Agent is described in the README as skill-driven rather than evaluation-driven. If your task has no measurable objective, the Summary phase has nothing reliable to summarise, and the memory accumulates noise instead of experience. That is a real failure mode, and it is the one to watch for. The second limitation is maturity. The release history shows v0.0.1 in January 2026 and v0.0.2 in February 2026. Two releases at the 0.0.x level means the API surface is young and you should expect it to move. The last push recorded is April 2026, so the project is active, but active is not the same as settled. Third, the framework is opinionated about the loop. If your problem is genuinely one-shot, or if you need to embed an agent inside an existing orchestration layer with its own control flow, LoongFlow's PES structure is overhead you will spend effort working around. It is not a general-purpose runtime that happens to support iteration. It is an iteration engine.

How LoongFlow Differs From General Agent Runtimes

The obvious comparison is to the general agent frameworks that most teams already have in place, the ones built around tool calling and a message loop. The difference in approach is where the state lives. In a tool-calling runtime, state is the conversation: the model sees the history and decides the next call. In LoongFlow, state is the experiential memory plus the current candidate, and the PES phases are what move it forward. The conversation is a means, not the container. That changes what you build. With a tool-calling runtime you write tools and prompts. With LoongFlow you write an agent directory: a task, an evaluation, and the domain knowledge that Planning should start from. A second comparison is to OpenEvolve-style evolutionary search, which the repository topics explicitly invoke. Classic evolutionary search operates on a population of programs with mutation and crossover operators. LoongFlow, as described, uses an LLM to generate the next candidate from the summary of previous ones, which is closer to guided search than to population-based search. Whether that is better depends on your problem: evolutionary search explores more broadly, and an LLM-guided loop exploits what it has already learned more aggressively. If your search space rewards broad exploration, the LLM-in-the-loop approach can converge early on a local optimum, and the README does not describe a mechanism for maintaining population diversity.

Maintenance Cost, Release Cadence, and the Apache-2.0 Licence

LoongFlow is Apache-2.0, which is a permissive licence that allows commercial use, modification and redistribution provided you keep the licence and notice files and state your changes. That is a standard arrangement and it is the same licence used by a large share of the Python agent ecosystem, so it will not raise procurement questions the way a copyleft licence would. This is a description of the licence terms, not legal advice; if you are embedding LoongFlow in a product, your own counsel should review the NOTICE requirements. The maintenance cost you should budget for is the version churn. Two releases in the first two months of 2026, both below 1.0, means you should pin the version in your dependency file and read the release notes before each bump rather than tracking the main branch. The Python 3.12 floor is a second cost. If your environment is on 3.11, adopting LoongFlow means a runtime upgrade across whatever else shares that interpreter, and that upgrade is usually larger than the LoongFlow integration itself. The third cost is the domain work. The framework gives you the loop and the memory; it does not give you the evaluation function, and for anything outside the three shipped agents that is the part you will spend the most time on. Budget for it explicitly. A team that assumes the framework supplies the scoring signal will find that the loop has nothing to optimise against.

Who Should Adopt LoongFlow and What to Check First

The fit is narrow and specific. You should look at LoongFlow if your problem is a search over candidate solutions where each candidate can be scored automatically, and if you want an LLM in the loop rather than a fixed mutation operator. Algorithm design, model architecture search, and optimisation problems with a clear objective all match the shape of the shipped Math-Agent and ML-Agent. You should not adopt it if you need a stable agent runtime for production orchestration, if your task is one-shot, or if you cannot define an evaluation function. The General-Agent is the weakest of the three fits for that reason, since the README describes it as skill-driven rather than objective-driven. Before you commit, verify these things in order. Confirm that your interpreter is Python 3.12 or newer, because the README badge sets that floor and there is no indication of backward support. Read the README inside agents/math_agent or agents/ml_agent, whichever is closer to your problem, and check that the evaluation interface it expects is one you can satisfy. Then read the arXiv paper at 2512.24077 for the claims behind the PES paradigm, since the top-level README asserts the benefits without quantifying them and the paper is the cited source. The repository's own topic list, which includes openevolve-alternative, is the clearest statement of what the authors think they are replacing. Judge it against that, not against general agent frameworks, and the trade-offs become legible.

Editorial conclusion

Adopt LoongFlow if your problem is genuinely iterative and you can supply a scoring function, because the PES loop and experiential memory only pay off when there is something to measure each round. Do not adopt it if you need a stable, documented agent runtime for production orchestration, or if your task is one-shot. Before committing, verify three things: that your Python is 3.12 or newer, that the agent directory you intend to use is present on the main branch, and that the release cadence between v0.0.1 and v0.0.2 matches the pace your team can absorb.

Official sources

1. baidu-baige/LoongFlow on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases