AutoAgents: A Rust Multi-Agent Framework With a WASM Tool Sandbox
A multi-agent framework written in Rust that enables you to build, deploy, and coordinate multiple intelligent agents
At a glance
- What is it?
- AutoAgents packages agent executors, typed tool calling, memory, and pluggable LLM backends behind Cargo feature flags, with Python bindings on PyPI. The interesting part is the sandboxed WASM tool runtime and the typed pub/sub channel between agents; the awkward part is that the provider matrix is uneven and the workspace build pulls in audio and TLS system libraries.
- Who is it for?
- Adopt AutoAgents if you are already writing Rust services and want agent execution, tool dispatch, and multi-agent messaging to share one type system rather than crossing a Python boundary. Do not adopt it if you need a provider whose row in the support table says No for tool calls or structured output, or if you cannot install libasound2-dev and libssl-dev on your build hosts.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 21 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem AutoAgents targets: agent loops that stay inside Rust's type system
Most agent frameworks assume Python. That is fine until the agent has to live inside a Rust service that already owns the request path, the connection pool, and the error types. AutoAgents is aimed at that case. The README describes it as a modular, multi-agent framework for building intelligent systems in Rust, combining a type-safe agent model with structured tool calling, configurable memory, and pluggable LLM backends. The stated audience is server and edge deployments, and the repository also ships Python bindings on PyPI, so the Rust core is not the only entry point.
The scope is broader than a single agent loop. The feature list covers agent execution (ReAct and basic executors, streaming responses, structured outputs), tooling via derive macros plus a sandboxed WASM runtime, sliding window memory, a unified LLM provider interface, guardrails, an optimization pipeline with cache and retry passes, typed pub/sub for multi-agent orchestration, local text-to-speech and speech-to-text, and OpenTelemetry tracing and metrics. That is a lot of surface area for one crate, and the sections below treat the uneven parts as uneven.
Executors, derive macros, and a WASM sandbox for tools
The mechanism the README makes explicit is a two-layer split. At the bottom sit executors: ReAct and basic. ReAct is the loop where the model alternates between reasoning and tool invocation until it produces a final answer. Above that, tools are declared with derive macros, and outputs can be declared the same way, which is how the framework gets structured output rather than parsing free text.
Tool execution has two paths. The first is ordinary Rust code compiled into your binary. The second is a sandboxed WASM runtime, listed under Tooling. The README does not describe the WASM host interface, the memory limits, or how a guest module is registered, so treat the sandbox as a stated capability rather than a documented contract. What can be said is that running untrusted tool code in WASM is a different trust model from calling a function pointer, and it is the design choice that separates AutoAgents from frameworks that only wrap local functions.
Multi-agent coordination is handled through typed pub/sub communication plus environment management. Typed channels mean the compiler checks the message shape between agents, which is the practical payoff of doing this in Rust instead of passing dictionaries. Memory is a sliding window with extensible backends, so the default retention policy is bounded context rather than unbounded history. Inference can be wrapped in guardrails, and the optimization layer composes passes such as cache and retry around the provider call.
The provider matrix is where the abstraction leaks
A unified LLM interface is only as good as its weakest row. The README publishes a support table, and reading it as a compatibility contract is more useful than reading it as a feature list.
Cloud coverage is uneven in specific ways. OpenAI, OpenRouter, Anthropic, DeepSeek, Groq, Google, and Azure OpenAI report chat, streaming, tool calls, and structured output. xAI reports no tool calls and model-dependent structured output. Phind reports no tool calls, no structured output, and streaming marked No with an asterisk. MiniMax reports structured output as No. The asterisk is explained: providers marked No for streaming fall back to the default ChatProvider::chat_stream implementation, which returns LLMError::Generic("Streaming not supported for this provider") instead of panicking. That is a sane failure mode, but it means a streaming call site compiles and then fails at runtime for those providers.
Multimodal support is equally provider-specific. Anthropic accepts images, image URLs, and PDFs through Anthropic content blocks. Google accepts inline images and PDFs but rejects image URLs with a typed error. Azure OpenAI accepts image URLs but rejects PDFs and raw inline images. OpenAI, OpenRouter, DeepSeek, Groq, and MiniMax accept OpenAI-compatible image inputs and reject PDFs. xAI and Phind are text-only and return LLMError::InvalidRequest on multimodal input. If your product depends on feeding PDFs to a model, the provider list narrows to Anthropic and Google.
Local inference is a separate table. Ollama, Mistral-rs, and Llama-Cpp all report chat, streaming, tool calls, and structured output, with vision support that is model-dependent for Ollama and explicit for the other two. Mistral-rs and Llama-Cpp run as embedded runtimes, while Ollama talks to a server. Burn and Onnx are listed as experimental and live in a separate repository, AutoAgents-Experimental-Backends.
Building the workspace: system packages, LeftHook, and feature flags
The prerequisites section is unusually concrete, and it is worth reading before cloning. On Debian-derived systems the README gives:
sudo apt update sudo apt install build-essential libasound2-dev alsa-utils pkg-config libssl-dev -y
The audio packages are there because of the local speech-to-text and text-to-speech features. If you do not want them, that is an argument for building a narrower feature set rather than the full workspace, but the README's own build command is the broad one:
git clone https://github.com/liquidos-ai/AutoAgents.git cd AutoAgents lefthook install cargo build --workspace --features full
LeftHook is required for Git hooks management and is installed via brew on macOS or npm install -g lefthook on Linux and Windows. Accelerator features such as CUDA, Vulkan, and Metal need matching local toolchains, and the README says to enable those only for the specific backend you are building. That is a real constraint: a full-feature build on a machine without the right GPU toolchain is not the intended path.
Python users have a shorter route. The bindings ship to PyPI, with a base package for core plus cloud providers and extras for local runtimes:
pip install autoagents-py pip install "autoagents-py[llamacpp-cuda]" pip install "autoagents-py[mistralrs-metal]" pip install "autoagents-py[guardrails]"
Extras combine, for example autoagents-py[llamacpp-cuda,guardrails]. Prerequisites for the Python path are Python 3.9 or newer, uv for environment management, and maturin to build or install local bindings from source. The README's development-install snippet is truncated at uv ve, so the exact local build command is not recoverable from the supplied material.
Where AutoAgents is the wrong tool
The clearest limitation is provider coverage. If you need tool calling on xAI or Phind, the table says no. If you need structured output on xAI, Phind, or MiniMax, the table says no or model-dependent. If you need streaming on Phind or Azure OpenAI, you get the default implementation that returns a typed error. None of these are bugs, but they mean the unified interface does not make providers interchangeable, and code that assumes otherwise will fail at the call site rather than the compile step.
The second limitation is the build surface. Requiring libasound2-dev, alsa-utils, and libssl-dev to build the workspace means the speech and networking features are not optional in the way the feature list implies. Teams building for a minimal container image will need to work out which features to disable, and the README does not spell out a minimal feature set.
The third is documentation depth. The WASM sandbox is named as a feature but the README does not explain its host interface, resource limits, or how a guest module is packaged. The optimization pipeline is described as cache and retry passes without a configuration example. The typed pub/sub layer is described as typed pub/sub plus environment management without a topology diagram or a code sample in the excerpt provided. Anyone evaluating those three subsystems is working from the crate documentation and the examples directory, not from the README.
The fourth is that this is a young project by its own release history. v0.4.0 landed in July 2026, following v0.3.7 in March and v0.3.6 earlier that same March. Three releases in roughly four months at the 0.3 to 0.4 boundary suggests the API is still moving. Pin your version.
How this differs from Python-first agent stacks
The obvious alternative is a Python framework such as LangChain or LangGraph, or a TypeScript one. The difference is not the feature checklist, which overlaps heavily, but where the boundary sits.
In a Python-first stack, the agent loop, the tools, and the orchestration all live in the Python process, and a Rust service calls into them over HTTP, a subprocess, or a binding layer. AutoAgents inverts that: the loop, the tool dispatch, the pub/sub channels, and the memory all live in the same Rust binary as the rest of your service. Errors are Rust enums like LLMError::InvalidRequest rather than exceptions crossing a language boundary, and agent messages are typed rather than dictionary-shaped.
The trade-off is ecosystem breadth. Python stacks reach more providers, more community tools, and more reference implementations, and the long tail of provider quirks is usually patched faster there. AutoAgents answers that partly with the Python bindings on PyPI, which let you use the Rust core from Python, and partly with the experimental backend repository for Burn and Onnx. But the bindings are a bridge, not parity: the README presents autoagents-py as the same framework with extras, and the local inference extras map directly onto the Rust crates.
A narrower alternative worth naming is calling a provider SDK directly from your Rust service and writing the ReAct loop yourself. That is perhaps a few hundred lines if you only need one provider, no sandbox, and no multi-agent messaging. AutoAgents earns its dependency weight when you need several of the listed subsystems at once, especially the WASM tool sandbox and the typed channels.
Licence and the maintenance cost of a moving 0.x API
AutoAgents is Apache-2.0. That is a permissive licence with an explicit patent grant, and it is compatible with commercial use and with distribution in a closed product. Apache-2.0 also requires that you preserve notices and state changes, and it includes a patent termination clause. This is a description of the licence text, not legal advice; if the agent framework ends up inside a shipped product, have counsel confirm the notice and attribution obligations that apply to your distribution model.
The maintenance cost is the one implied by the release cadence. Three releases between March and July 2026, with the latest at v0.4.0, means minor versions can carry breaking changes. Practical consequences: pin the crate version in Cargo.toml rather than tracking main, and expect to re-read the provider table on upgrade, because a row that says Yes for tool calls today can change as backends are reworked. The separate experimental repository for Burn and Onnx also means those backends are versioned independently of the core, so a Burn upgrade is not gated by an AutoAgents release.
On the operational side, the OpenTelemetry integration with pluggable exporters is the piece that determines how much of this you can observe in production. The README lists tracing and metrics but does not name default exporters or sampling configuration, so that is another item to verify against the crate documentation before you rely on it for incident response.
Editorial conclusion
Adopt AutoAgents if you are already writing Rust services and want agent execution, tool dispatch, and multi-agent messaging to share one type system rather than crossing a Python boundary. Do not adopt it if you need a provider whose row in the support table says No for tool calls or structured output, or if you cannot install libasound2-dev and libssl-dev on your build hosts. Before committing, build with cargo build --workspace --features full, then check the feature name for your chosen provider against the table and confirm whether that provider returns a typed error or a default streaming stub.
Community notes