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

The problem any-agent solves: framework choice as a rewrite

Pick an agent framework and your code is written against that framework's classes, tool signatures and execution model. Switch from LangChain to the OpenAI Agents SDK and the agent definition, the tool wrappers and the run call all change. For anyone comparing frameworks on the same task, that means maintaining parallel implementations and hoping the differences you measure come from the frameworks rather than from your own porting mistakes.

any-agent targets that specific situation. The README calls it "a single interface to use and evaluate different agent frameworks", and the supported list is Agno, Google ADK, LangChain, LlamaIndex, OpenAI Agents SDK and smolagents, with TinyAgent as the default in the quickstart. The audience is not someone shipping a single production agent. It is someone who needs the same agent, the same tools and the same evaluation to run on more than one backend, and who wants the framework to be a string argument rather than a rewrite.

How the abstraction works: AgentConfig in, AgentTrace out

The interface has two moving parts. AgentConfig carries the model identifier, the instructions and the tool list. AnyAgent.create takes a framework name as its first argument plus that config, and returns an agent. The framework name is what selects the backend, so the same config object can be handed to a different framework without editing the agent definition.

The quickstart shows the model addressed as a provider-prefixed string, "mistral:mistral-small-latest", which means model routing is delegated rather than hardcoded to one vendor. The run call returns an agent_trace object rather than a bare string, which is where the evaluation story starts: tracing is listed as a core concept alongside serving and evaluation, and the package depends on opentelemetry-sdk, so traces are the shared artifact the evaluation layer reads. That is the architectural bet. Normalise the agent definition on the way in and normalise the trace on the way out, and the framework in the middle becomes interchangeable.

Installing any-agent and running a first agent

The base package installs on its own, and each framework is an optional extra. The README's install line is deliberately plain, and pyproject.toml defines extras named agno, google, langchain, llama_index, openai and smolagents, plus a2a and composio. Installing the base package plus the framework you intend to run is the pattern.

pip install 'any-agent'

A model provider key is needed next. The README uses Mistral for its example and notes that the relevant key depends on the provider.

export MISTRAL_API_KEY="YOUR_KEY_HERE"  # or OPENAI_API_KEY, etc

The imports are the same regardless of backend, which is the point of the package.

from any_agent import AgentConfig, AnyAgent

The agent itself is built from a framework name, a config and a tool list. The README's example uses search_web and visit_webpage from any_agent.tools and the tinyagent backend.

from any_agent.tools import search_web, visit_webpage

agent = AnyAgent.create(
    "tinyagent",  # See all options in https://docs.mozilla.ai/any-agent/
    AgentConfig(
        model_id="mistral:mistral-small-latest",
        instructions="Use the tools to find an answer",
        tools=[search_web, visit_webpage]
    )
)

agent_trace = agent.run("Which Agent Framework is the best??")
print(agent_trace)

What you should see is the printed trace for that run, not a plain answer string. Two practical notes from the README: in Jupyter you may hit RuntimeError: This event loop is already running, which the README attributes to a known Notebook limitation and works around with nest_asyncio.apply() before running AnyAgent. The quickstart also points at pyproject.toml for the available install options, so check the extras there rather than guessing a framework name.

Soft deprecation is the first thing to weigh

The README carries an explicit notice that any-agent is in soft deprecation. It says the project started as a research effort to compare frameworks and distil a minimal common surface, that this distillation graduated to mozilla-ai-tinyagent, and that new projects should use tinyagent directly. It also states that any-agent continues to be published and that security and bug-fix pull requests will be taken, but that no new features are planned.

That changes the adoption calculus more than any technical detail. A framework added to the ecosystem in six months is unlikely to get an extra here, and the README's own guidance is to reach for any-agent only when you specifically need to run or evaluate agents across multiple frameworks under one API. The last push to the repository was on 2026-09-01, so the project is not abandoned, but the roadmap is closed. Treat any multi-framework comparison you build on it as a tool with a maintenance horizon, and read the successor package before you start.

When any-agent is the wrong layer

If you have already chosen your framework, any-agent adds a dependency and a translation layer for no benefit. You would be calling AnyAgent.create with one string forever, and debugging through an abstraction that exists to make that string swappable. The README is direct about this: tinyagent is the leaner path when you only need the core agent loop.

The second case is narrower than it looks. The package depends on any-llm-sdk, mcp, opentelemetry-sdk, pydantic, requests, rich and tavily-python, and the optional extras pull in the full framework trees, some of which are large. Installing the all extra brings in Agno, Google ADK, LangChain, LlamaIndex, OpenAI Agents SDK and smolagents together. When you actually need one of those frameworks in production, installing it directly avoids carrying the other five and the abstraction on top of them. Multi-agent work is also not a first-class primitive here: the README points to implementing it through Agents-As-Tools rather than a dedicated orchestration API.

Alternatives and the real difference in approach

The README names the successor directly. mozilla-ai-tinyagent, published as mozilla-ai-tinyagent on PyPI, is the distilled core that came out of this project. The difference is scope rather than quality: tinyagent is a single agent loop, while any-agent exists to run the same agent across Agno, Google ADK, LangChain, LlamaIndex, OpenAI Agents SDK and smolagents and to evaluate the results. If your reason for looking at any-agent is that you want one clean way to define an agent, tinyagent matches that need. If your reason is that you want to measure three frameworks against the same task, tinyagent does not replace it.

Staying inside one framework is the other alternative, and it is the honest default. LangChain, LlamaIndex, Google ADK and the OpenAI Agents SDK each ship their own tracing and evaluation tooling, and using them means no translation layer between your code and the framework's own abstractions. You give up portability across frameworks. The trade is only worth making when portability is the thing you are actually measuring.

Licence, dependencies and upgrade cost

The package is Apache-2.0, declared both in pyproject.toml and the repository metadata. That is a permissive licence with a patent grant, and the practical consequence for adopters is that you can ship it in a closed product as long as you keep the licence notice and the NOTICE-style attribution intact. It says nothing about the frameworks you install alongside it, which carry their own licences and their own terms. Check those separately, and treat this as a description of the licence file rather than legal advice.

Upgrade cost is dominated by the extras. The core dependencies use bounded ranges such as any-llm-sdk>=1.0,<2 and mcp>=1.5.0, while the framework extras carry their own ceilings: agno>=1.7.0,<2, openai-agents>=0.3.0,<1, llama-index>=0.12.52,<1, a2a-sdk>=0.3.0,<1.0.0. Those ceilings are what keep a framework's breaking release from reaching you, and they are also what will eventually hold you back. Python support is >=3.11,<3.14, so a 3.14 environment is outside the declared range. With no new features planned, expect to move off any-agent rather than to grow with it.

Editorial conclusion

Adopt any-agent when the task is comparing or evaluating the same agent across several frameworks under one interface, and pin the framework extras you actually install. Skip it for new projects that only need a core agent loop, because the README points those to mozilla-ai-tinyagent and states no new features are planned here. Before committing, verify that your target framework still has an extra in pyproject.toml, that your Python version sits inside >=3.11,<3.14, and whether any future security fix reaches this package or only its successor.

Frequently asked questions

Official sources

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