Spring AI AgentX

The deciding trait is what it refuses to be. There is no graph builder here, no workflow designer, no second mental model to learn: it is an execution engine you wire into an application you already know how to deploy. For a team that lives in this ecosystem, that is the shortest distance between a ticket and a working agent.

You are the wrong buyer if your stack is anything else, because the whole value is the ecosystem fit. Pick it inside a Spring application. Pick a Python framework if you are starting from nothing.

Look at the version. The artefact you would add to a build file is a milestone, and behind it sit sub-agents, hooks, snapshots, approval tools, tracing and a sandbox, which is an enormous amount of behaviour to stabilise before a first release. Milestone versions change interfaces. A dependency that changes interfaces is a schedule you do not control.

What it does right is fail closed. The strict mode refuses rather than degrades, which is the correct default for anything that can run a shell command.

1. Context is modelled explicitly. A session exists in original, working and offload states, and compaction proceeds through six described levels, which means degradation is staged and legible instead of arriving as a single truncation nobody can reconstruct afterwards. 2. Long-term memory is extracted asynchronously into an external store and injected per user, separating retention from the request path.

2. Sub-agents receive their own windows, so delegation is also context isolation. No evaluation is published and none is claimed.

167 stars is a small number, and the more important number is the size of the framework this sits on top of. Building the missing layer above a large vendor's platform is a good way to be useful and a poor way to be safe, because the platform ships that layer eventually and calls it a release note.

Moat: none, and the ecosystem it serves belongs to somebody else. Likely acquirer: none; the likelier outcome is absorption by convergence. Position: use it, keep your own interfaces between it and your code, and expect to replace it.

Two controls here would survive a security review. Execution tools are confined to a container or a restricted directory with isolation drawn per conversation or per user, and traces are audited by the library itself, so an incident has a record without us building one.

There is no seat cost, because this is a dependency inside a service my team operates, which means identity and retention are inherited from that service rather than purchased here. Approved with conditions: the container path in production, and provider spend bounded in the service that wraps it.

Seven lifecycle hooks is the number that matters to me. It means the interesting points in the loop are exposed as extension slots, so changing behaviour is registering a handler rather than patching a class and maintaining a diff forever. That is what a framework owes anyone who intends to use it seriously.

Apache-2.0, MCP servers attach beside the native tools, and execution can be pinned to a restricted local directory when I do not want a container in the way. The models are whatever the underlying platform is pointed at.