any-agent: One API Across Six Agent Frameworks, Now in Soft Deprecation

The Multi-Framework Comparison Problem any-agent Was Built For

Choosing an agent framework usually means writing the same agent several times. Each framework has its own agent class, its own tool decorator, its own way of passing a model identifier and its own trace format, so a fair comparison costs a week of porting before you learn anything. any-agent collapses that porting work. The README describes it as "a single interface to use and evaluate different agent frameworks", and the supported list is explicit: TinyAgent, Google ADK, LangChain, LlamaIndex, OpenAI Agents SDK, smolagents and Agno. The audience is therefore narrow and specific. It is for engineers who need to run or evaluate agents across several of those frameworks under one API, not for someone who has already picked one and wants the shortest path to a working agent. The README's own soft deprecation notice draws exactly that line: reach for any-agent when you specifically need multiple frameworks, and use mozilla-ai-tinyagent when you only need the core agent loop.

How AnyAgent.create Dispatches to a Framework

The mechanism visible in the README is a string-keyed factory plus a shared configuration object. You import AgentConfig and AnyAgent from any_agent, then call AnyAgent.create with a framework name as the first argument and an AgentConfig as the second. In the quickstart that name is "tinyagent", and the README says all options are listed in the documentation. The AgentConfig carries model_id, instructions and tools. Tools come from any_agent.tools, which the example populates with search_web and visit_webpage, so the same tool objects are handed to whichever backend you selected. The return value is an agent whose run method takes a plain string and returns an agent_trace object. That trace object is the second half of the design: because the interface is uniform, the trace is uniform too, which is what makes cross-framework evaluation possible at all. The README also notes that multi-agent setups are expressed through Agents-As-Tools rather than a separate orchestration API, and that Model Context Protocol tools are covered by a dedicated cookbook. The trade-off is visible in the same design. A lowest-common-denominator surface means framework-specific features that do not fit AgentConfig have nowhere obvious to go.

Installing any-agent and Setting a Model

Requirements are Python 3.11 or newer. The quickstart install is a single command, pip install 'any-agent', with the README instructing you to update your pip install command to include the frameworks you plan to use and pointing at pyproject.toml for the available options. That phrasing matters: the extras are how per-framework dependencies arrive, and the README does not enumerate them inline. Model access is configured through environment variables. The example exports MISTRAL_API_KEY and pairs it with model_id="mistral:mistral-small-latest", noting that OPENAI_API_KEY and equivalents work for other providers, with model configuration documented separately. The minimal program is three lines of setup and one call: create the agent with instructions "Use the tools to find an answer", run it with a question string, print the returned trace. One environment quirk is documented rather than hidden. In Jupyter, the README says you may hit RuntimeError: This event loop is already running, and the fix is to import nest_asyncio and call nest_asyncio.apply() before running AnyAgent. It is described as a known limitation of Jupyter Notebooks, not of any-agent itself.

Soft Deprecation Is the Constraint That Should Shape Your Decision

The most consequential line in the repository is the deprecation notice, and it is unusually candid. any-agent is in soft deprecation. It began as a research project to compare agent frameworks and distil a minimal common surface, and that distillation has graduated to a separate package, mozilla-ai-tinyagent, published on PyPI as mozilla-ai-tinyagent. The README states that any-agent continues to be published and that security and bug-fix pull requests will be taken, but no new features are planned. For an adoption decision this is the whole ballgame. You are choosing a maintained but frozen surface. The supported framework list will not grow on its own; the README routes new framework requests to open GitHub tickets labelled frameworks and invites contributions, which is a way of saying the growth path is external. If your framework is not already on the list, the answer is not a roadmap date. It is a pull request you would have to write. Treat the frozen state as a design constraint, not a temporary condition.

Tracing, Serving and Evaluation as Separate Core Concepts

The documentation splits into agents, tools, tracing, serving and evaluation. Those last three are where any-agent does more than wrap constructors. Tracing is the substrate: because every run returns a trace object regardless of backend, you get a comparable record of what the agent did. Evaluation is built on top of that, and the cookbook includes a first-agent-evaluation walkthrough that the README says evaluates a web search agent using three different methods. Serving is the A2A story, with cookbooks for serving an agent over Agent-to-Agent communication and for building multi-agent systems where one A2A agent acts as a tool for another. This is the part of the project that has no obvious equivalent in the frameworks it wraps, since each of them exposes its own tracing and its own serving story. It is also the part most exposed to the deprecation: the evaluation and serving surfaces are what a research project accumulates, and they are the surfaces least likely to receive new work now. The README does not state a compatibility guarantee for trace formats across releases.

tinyagent Is the Alternative, and the Difference Is Scope

The named alternative is not a competitor framework. It is mozilla-ai-tinyagent, the package the README says this project's distillation graduated into. The difference in approach is scope, not quality. any-agent keeps a dispatch layer, a shared AgentConfig, a common trace and the evaluation and serving machinery needed to compare six backends. tinyagent is described as the leaner path for the core agent loop alone. If you have already decided on one framework, or you do not need a framework at all, the dispatch layer is pure overhead: an extra dependency, an extra indirection between your code and the backend, and a configuration object that must express your needs in a shared vocabulary. The README's recommendation is unambiguous on this point, stating that for new projects it recommends using tinyagent directly. Choosing any-agent for a single-backend agent means adopting a deprecated wrapper to get a feature you are not using.

Maintenance Cost, Licence and What to Verify Before Adopting

Maintenance cost here is mostly upgrade cost, and the shape of it is set by the extras model. Because frameworks are installed as options alongside the base package, a major release of Google ADK or LangChain can force a coordinated bump on your side, and the README does not promise that the shared surface will absorb breaking changes in a wrapped framework. The project is published under Apache-2.0, which permits commercial use and modification, but this is a description of the licence identifier in the repository metadata, not legal advice; read the licence text and your own obligations. The release cadence visible in the supplied material is frequent and recent, with 1.16.1, 1.17.0 and 1.18.0 appearing within about a week in February 2026, so pinning a version is worthwhile. Before adopting, verify the framework extra you need is actually installed, since the base install command in the README is bare. Verify your model_id prefix and API key pair resolve. And verify the framework you care about appears on the supported list, because the README's answer for anything missing is an open ticket, not a planned release.

Editorial conclusion

Use any-agent when the multi-framework comparison is the actual goal: you want to run or evaluate the same agent definition against Agno, Google ADK, LangChain, LlamaIndex, OpenAI Agents SDK and smolagents under one API, and you accept that no new features are planned. Do not start a new single-framework agent on it; the README points that case at mozilla-ai-tinyagent. Before committing, verify two things in your own environment: that the framework extra you need is installed alongside the base package, since pip install 'any-agent' alone does not pull in every integration, and that your chosen model_id prefix resolves with the matching API key exported. Check the open framework tickets if the framework you actually use is not on the supported list.

Official sources

1. License: Apache-2.0
2. mozilla-ai/any-agent on GitHub
3. Project website
4. README
5. Releases