LightAgent ships two dependency files that disagree on three pins

Ten READMEs, a capitalised package, docs on someone else's Pages

The repository root is a language matrix before it is anything else. There are ten README files: English, Simplified and Traditional Chinese, Spanish, French, German, Japanese, Korean, Portuguese and Russian.

The Poetry manifest lists nine of them in its readme field, with the English one first. The Traditional Chinese file is the one missing from that array, which is a small packaging inconsistency rather than a translation gap.

The package itself is named with a capital letter. The distribution is LightAgent and the directory it ships is LightAgent, and the same capitalisation appears in the manifest's package include entry. The documentation badge points to a GitHub Pages site hosted under a different organisation name from the repository owner, which tells you the docs live with a lab rather than with the project account.

Around that sit the files a project of this size tends to accumulate: a FAQ, a roadmap, a security policy, a code of conduct, a contributing guide, a changelog, a Makefile, a lock file, and separate directories for documentation, examples, tests, skills and MCP material. The MCP material has its own release notes file and a Simplified Chinese counterpart, which suggests the MCP surface is documented as a component in its own right rather than as a chapter.

Two dependency files, three different pins

There are two dependency declarations in the repository and they do not agree.

The Poetry manifest uses a mixture. Some packages are pinned exactly, including the logging library, the HTTP client, a terminal colour library, the SSE transport and the settings library. Others carry ranges, including the OpenAI client, the MCP client, the memory library and the tracing library.

The pip requirements file pins three of those ranged ones instead:

mcp==1.10.1

with the tracing library at exactly 3.0.0 and the memory library at exactly 0.1.70, while the manifest asks for 1.9.0 or newer, 3.0.0 or newer and 0.1.70 or newer respectively. The object storage client is present in the manifest as an optional dependency and appears in the requirements file only as a commented line, with the note that it is for object storage uploads.

That file also spells the HTTP library with a capital letter, which works because package names are normalised, but it is the kind of detail that makes a diff between the two files harder to read.

The practical question is which one your install consults. If you install through the manifest you get the newest compatible releases of those three packages; if you follow the requirements file you get the versions the author tested against. Both are defensible, and having them differ quietly is not.

The build runs Poetry through uv, pinned per invocation

The Makefile is four targets and one unusual decision.

POETRY := uv tool run --from poetry==2.4.1 poetry

Rather than calling a locally installed Poetry, every target invokes Poetry through uv's tool runner with the version pinned inline. A check-tools target verifies that uv is on the path first, so a machine without uv fails immediately with a clear message instead of an unresolved command.

The remaining targets are conventional: help prints a self-documenting list generated by grepping the Makefile for comment markers, setup runs an install including the development group, update relocks and reinstalls, and build produces a wheel.

There is also a lock file at the repository root, so the versions used in continuous integration are recorded even though the tool invoking them is not installed globally.

This is a small file and it says something about the project's shape. A framework that vendors its own build tool version is a framework where reproducibility of the build matters more than convenience, which matches the rest of the release notes, where the 0.9 series added a public API compatibility inventory in preparation for version 1.0.

The changelog marks some versions as development

The news list at the top of the README is the closest thing to a changelog, and it uses two different labels. Several entries are marked as released while others are marked as development, and the distinction does not map cleanly onto the release list.

The most recent entry is dated 2026-10-01 and announces version 0.11.0 as released, while the release itself was published on 2026-09-30, so the announcement and the tag are a day apart. Two entries share the date 2026-08-15, one announcing 0.10.0 and one announcing 0.9.7, which means those two lines of development shipped on the same day.

The version sequence also skips. The visible history runs 0.6.4, 0.6.5, 0.7.0, 0.8.0, 0.8.1, 0.9.0, 0.9.3, 0.9.6, 0.9.7, 0.10.0, 0.10.1, 0.10.2 and 0.11.0. Nothing explains the gaps, and if you are pinning a version in a deployment you may find gaps between published and listed versions.

The cadence itself is fast: eleven entries between late May 2026 and October 2026, with the most recent three releases two and a half weeks apart. The manifest still calls the project Beta, its classifiers stop at Python 3.13 while the manifest allows anything from 3.10 up to 4.0, and the last push to the default branch was the same day as the 0.11.0 release.

0.11.0 is about permissions, not features

Read the two most recent release notes together and the direction is clear.

Version 0.11.0 adds opt-in persistent dynamic DAG execution across multiple agents, verification-gated immutable artifacts, restart-safe leases with fencing, and a unified security context that narrows rather than widens, with capability and approval controls. Every clause in that sentence is about who is allowed to do what and about surviving a restart without two workers believing they own the same work.

Version 0.10.0 is the bigger structural change underneath it: a unified event-sourced agent runtime with durable sessions, asynchronous execution, a capability registry and policy layer, inboxes, goals and budgets, compaction and recovery, jobs and subagents, standardised adapters for skills and MCP, and SQLite full-text search retrieval.

That combination changes what you are adopting. A framework you call from your own process is a library. A framework with durable sessions, budgets and compaction is a system that expects to be operated, with leases and fencing to keep concurrent workers honest.

The earlier entries show the same instinct applied to safety: 0.9.6 added durable human approval for tools along with fail-closed admission for shared graph memory and audit controls, and 0.9.3 added a cap on tool iterations during streaming plus consistent error and after-run closure.

Three memory adapters in the examples directory

Memory is where this framework has more than one answer, and the examples directory makes that visible rather than hiding it.

The feature list names native support for one memory module and automatic management of per-user personalised memory, alongside custom long-term memory per user. The examples then ship adapters for at least three: a numbered example for the natively supported module, a separate adapter file for a second memory system, a third adapter file for another, and a numbered example for a vector memory adapter.

The version history shows the same area being refined rather than replaced. The 0.8.1 entry adds memory scope metadata conventions and stricter provenance filters, with guidance for separating trace data, user memory, self-reflection memory and swarm delegation state. The 0.9.6 entry adds fail-closed admission and audit controls for shared graph memory. The 0.9.7 entry adds an opt-in security matrix for one of the graph memory integrations.

Shared memory across agents is described as a prototype: an append-first in-memory pool with provenance metadata, scoped retrieval, and results shaped to be compatible with the memory policy object. Calling it a prototype in the feature list while shipping a policy layer around it is an honest pairing, and the provenance filtering is the part that decides whether an agent can read another agent's notes.

LightSwarm delegates, LightFlow decides

The multi-agent story is two systems with different philosophies, and the feature list is careful about the difference.

One is LightSwarm, which does intent recognition and task delegation, letting an agent hand work to other agents as needed. That is the open-ended path, where the model decides who does what, and the claim made for it is that multi-agent collaboration is simpler here than with a framework built for it.

The other is LightFlow, which chains agents into deterministic multi-step workflows with explicit dependencies, output passing between steps, retries, checkpointed run records, resume and rerun support, approval nodes, fallback agents and traceable execution. That is the closed path, where the sequence is written down in advance and the framework's job is to run it, resume it after a crash, and record what happened.

The 0.11.0 release extends the deterministic side rather than the delegated side, adding persistent dynamic DAG execution, which is the point where a workflow's dependency graph is built at run time rather than declared in advance.

The examples reflect both, with numbered files for a single agent, tools, memory, multi-agent, self-learning, chat history, MCP, browser use, custom tools, LightFlow, a vector memory adapter, a cloud integration, the 0.10 runtime and dynamic DAG execution, plus directories for connectors and tools.

Editorial conclusion

LightAgent is worth trying if you want an OpenAI-compatible agent stack without LangChain or LlamaIndex in the dependency tree, and if you want both a delegating swarm layer and a deterministic workflow engine rather than picking one. Three things to check first. Which dependency file your install actually reads, since the Poetry manifest and the pip requirements file pin three packages differently and choosing one silently changes what you run. Whether you want the runtime in the picture at all, because the 0.10 series added an event-sourced runtime with durable sessions, budgets and compaction, which is the difference between a library you call and a system you operate. And what your trust boundary is, because 0.11 narrows into a security context with capabilities and approvals, durable human approval for tools appeared in 0.9.6, and tracing goes to Langfuse as a hard dependency rather than an extra.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. wanxingai/LightAgent on GitHub