infiAgent (MLA V3): a config-driven runtime for agents that run for days

The failure mode infiAgent is built around: context that grows until the agent dies

Most agent frameworks degrade in a predictable way. A task runs for hours, the conversation history and tool results accumulate, and eventually the context window fills. Compression kicks in, the compressed summary loses details the agent needed, and the run either drifts or crashes. The README names this directly: infiAgent is designed for unlimited runtime without tool calling chaos or system crashes caused by cumulative task resources and conversation history. That is the problem statement, and it is a narrow one. This is not a framework for building a chatbot or a retrieval pipeline. It is for tasks where the interesting work happens on day three, after a hundred tool calls, and where stopping and restarting should not cost you the run. The stated audience is engineers building general-purpose and semi-specialized agents who would rather write configuration files than orchestration code. The README gives two named examples of that: a `Researcher` config for long-running scientific research with paper generation, and an `OpenCowork` config for broad general-purpose tasks. If your task completes in a single context window, the machinery described here is overhead you will pay for and never use.

Two architectures from one runtime: a tree of sub-agents or a single agent with skills

MLA stands for Multi-Level Agent, and the name describes the orchestration model. The README describes two supported shapes. The first is a multi-level hierarchy, a tree-structured orchestration for complex domain tasks, with the `Researcher` config as the example. The second is flat: a single agent with one sub-agent plus Skills, used for broad general-purpose tasks, with the `OpenCowork` config as the example. Both run on the same execution loop. The runtime itself, published as the `infiagent` package, ships the agent execution loop, the context builder, the tool executor, a built-in level-0 tool suite, an LLM client with multi-provider failover, a concurrency-safe experience store and the SDK entry point. The practical consequence of the tree model is that context is scoped per agent rather than shared across the whole run. The March 2026 notes describe this for CheapClaw, an application built on the SDK: different tasks under the same bot keep isolated contexts, while messages routed to the same task continue in the same long-running context. That is the design decision worth understanding. Isolation is per task, not per session, which is what makes a multi-day run tractable in the first place.

Persistence, atomic writes and the experience store

The July 2026 release notes describe the persistence layer in more detail than most projects bother to publish. All runtime persistence, covering the execution stack, task state and experience files, uses atomic writes: a temp file in the same directory, then fsync, then rename. The stated consequence is that power loss cannot produce half-written state. Corrupted legacy state files are quarantined automatically, and the notes claim interrupted tool calls replay idempotently on resume. That last claim is the one to be sceptical about, and the documentation is honest about the boundary: idempotent replay is a property of the tool, not of the framework. A tool that charges a credit card is not made safe by an atomic rename. The experience store is a separate mechanism. It uses cross-process file locks covering the full read-modify-write, uuid-based entry ids, file revisions with optimistic concurrency checks via `expected_revision` and `expected_updated_at`, transactional writes across task and global scope with rollback, and only entries with `status=active` are injected into agent context. That last filter matters: an experience you have retired stays on disk but stops influencing behaviour. Memory itself is file-directory based. Launch agents in the same workspace directory and they remember historical tasks across sessions, with no external database required.

Getting it running: the PyPI runtime, the Docker Web UI and the config keys

The repository now tracks the backend runtime only. The README states that desktop app, marketplace and other application layers have moved out of this repository, and points to `RUNTIME.md` for notes on this build. Installation is a single command: `pip install infiagent==3.12.24`, which the README says brings the execution loop, context builder, tool executor, level-0 tool suite, LLM client, experience store and SDK entry point, plus the full test suite. Python 3.9 or later is required. For the Web UI, the documented path is the Docker image `chenglinhku/mlav3:latest` started with the `webui` command on port 4242, mounting `~/.mla_v3` to `/root/mla_v3` and publishing 4242. The March 2026 notes say the older standalone config page on port 9641 is no longer required. Model configuration lives in `llm_config.yaml`. A model entry can declare a `deployments` list holding multiple API keys or platforms serving the same logical model. Healthy traffic sticks to the primary deployment to preserve provider-side prompt caching; rate limits, timeouts and auth failures move a deployment into cooldown and fail over to the next. The single-key form still works. Per sub-agent, the README lists `execution_model`, `thinking_model`, `compressor_model`, `image_generation_model` and `read_figure_model` as independently configurable. The SDK also accepts structured model profiles directly, so you are not forced to hand-write YAML.

Thinking mode, ReAct mode and the task_history_search tool

The March 2026 release added a switchable cadence model, and it is the setting most likely to change how a run behaves. You can keep the ThinkingAgent-style plan-first-then-execute-N-steps workflow, or disable thinking and fall back to an explicit ReAct loop where reflection text is persisted directly inside the message history. These are genuinely different trade-offs. Thinking mode front-loads planning and keeps the history cleaner. ReAct mode writes reasoning into the transcript, which makes the run easier to audit but consumes context that the long-horizon design is trying to protect. The same release added a local SQLite index of historical task records and a built-in `task_history_search` tool. The SDK can expose only the most recent N historical tasks into prompt context, and agents are instructed to retrieve older history from the database when recent context is insufficient. That is a two-tier memory design: recent tasks inline, everything else behind a tool call. It also means the agent's recall of its own past depends on it deciding to search, which is a behaviour you can only evaluate by running your own workload. The release notes describe the mechanism; they do not claim a recall rate.

Where it breaks: GPL-3.0, a split repository and a thin operations story

Three constraints deserve attention before adoption. The licence is GPL-3.0, which is a copyleft licence. If you embed this runtime in a distributed product, the licence obligations follow the combined work. That is a business decision, not a technical one, and this article is not legal advice; read the GPL-3.0 text and, where the stakes are high, talk to counsel. Second, the repository has been split. The runtime is on PyPI, but the desktop app and marketplace have moved elsewhere, so a reader looking for the full application should expect to follow links rather than find everything in one tree. The README also warns that if you pulled the image or code before the latest update, you should check which issues were fixed and re-pull as needed. That is a maintenance tax on anyone tracking the project. Third, the operational surface is real but narrow. Atomic writes, file locks and optimistic concurrency are the right primitives for crash safety, yet they say nothing about observability. The material describes a `task_history_search` tool and a SQLite index, not a dashboard or a tracing integration. If you need to answer what the agent did at 3am on day two, you will be reading state files. The v1.4.1 release note mentions fixing hang issues and optimizing performance, which suggests the long-running path has had rough edges in the recent past.

How it differs from LangGraph and from single-shot agent loops

The closest comparison in the same problem space is LangGraph, which also targets stateful, long-running agent workflows. The difference is where the state lives and who controls the graph. LangGraph keeps checkpoints in a configurable store, typically a database, and you define the graph in Python: nodes, edges, conditional routing. infiAgent keeps state in files under a workspace directory and defines the agent structure in config files, with the tree of sub-agents or the flat single-agent-plus-skills shape chosen by which config you load. The README's framing is explicit: build agents just by editing config files. That is a real convenience for the common case and a real ceiling when your orchestration does not fit either shape. The other comparison is the plain ReAct loop you would write yourself in an afternoon. For a task that finishes in one context window, a hand-rolled loop plus your own prompt is less machinery and less to debug. infiAgent earns its complexity only when the run is long enough that crash recovery, context isolation per task and a searchable task history change the outcome. If you cannot point to a task that runs for hours, the framework is answering a question you have not asked.

Maintenance cost and upgrade path

Upgrades here are not drop-in. The project has moved through v1.4.1, V2.0.0, and a version 3.2.1 badge in the README, with the runtime now versioned separately on PyPI as 3.12.24. The V2.0.0 notes list history task truncation, query support and thinking on/off toggles as new. The July 2026 notes describe corrupted legacy state files being quarantined automatically, which implies that state written by older versions may not load and that you should expect a migration step rather than a silent upgrade. Pinning the runtime version in your dependency file is the only way to make that predictable. On the configuration side, the project has been moving away from hand-written YAML toward structured model profiles in the SDK and source-based editors in the desktop and Web UI, while keeping raw YAML and JSON as fallbacks. That reduces the cost of adding a model but adds a second configuration path to keep in sync. For a team running one agent in one workspace, this is manageable. For a team running many agents across many workspaces, the file-directory memory model means backup, migration and cleanup are your problem, and the material does not describe tooling for any of the three.

Editorial conclusion

Adopt infiAgent if you need an agent loop that survives crashes and restarts across days, and you are willing to define behaviour in YAML config files and skill folders rather than Python. Do not adopt it if you need a permissive licence for a closed product, if you want a mature hosted control plane, or if your tasks finish in minutes and a simple ReAct loop is enough. Before committing, verify three things: that `pip install infiagent==3.12.24` installs cleanly on your Python 3.9+ environment, that the GPL-3.0 obligations fit how you ship, and that the resume path actually replays your own tool calls idempotently, since the README states interrupted calls replay that way but the guarantee depends on how you write the tools.

Official sources

1. Issues
2. License: GPL-3.0
3. polyuiislab/infiAgent on GitHub
4. README
5. Releases