AutoAgents decides provider support in a table, and the build asks for everything at once

The provider table records what each backend refuses

The support matrix is six columns wide and reads like a compatibility report rather than a feature list. Vision and PDF handling is where the providers differ most. Anthropic takes images, image URLs and PDFs as content blocks. Google takes inline images and PDFs but rejects image URLs with a typed error. OpenAI, OpenRouter, DeepSeek and Groq take image URLs and inline images and reject PDFs with a typed error, which is four of the ten cloud backends failing one input type each. Azure OpenAI is stricter still, accepting image URLs while rejecting both PDFs and raw inline images. xAI and Phind are text-only chat, and their row says multimodal input returns `LLMError::InvalidRequest`. Two columns say No without a caveat: xAI has no tool calls, MiniMax has no structured output, and Phind has neither tool calls nor structured output. Nothing here is a silent degradation, which is the part that makes the table worth reading.

Streaming gaps return an error instead of panicking

Two cloud providers are marked No for streaming, Phind and Azure OpenAI, and both carry an asterisk. The footnote explains what that asterisk costs: providers marked No use the default `ChatProvider::chat_stream` implementation, which returns `LLMError::Generic("Streaming not supported for this provider")` rather than panicking. So the failure mode for a code path that streams against Phind is a typed error value at runtime, not a crash, and not a silent empty stream that a caller might mistake for a finished response. Ollama, Mistral-rs and Llama-Cpp are all Yes across chat, streaming, tool calls and structured output, and the local table adds a column the cloud table does not have, local inference, marked Yes via an Ollama server for the first and Yes with an embedded runtime for the other two. Vision on the local side depends on the model for Ollama, on vision models supported for Mistral-rs, and on vision models with projector files for Llama-Cpp.

The build command turns everything on, and the note says not to

Clone, hooks, build:

git clone https://github.com/liquidos-ai/AutoAgents.git
cd AutoAgents
lefthook install
cargo build --workspace --features full

The next paragraph says hardware-specific accelerator features such as CUDA, Vulkan and Metal require the matching local toolchains and platforms, and that those features should be enabled only for the specific backend being built. Those two instructions do not line up: the documented command asks for the full feature set across the workspace, and the sentence after it asks you to keep features off unless they match your hardware. The system prerequisites sit on the same footing, because the apt line is not a minimal build line:

sudo apt update
sudo apt install build-essential libasound2-dev alsa-utils pkg-config libssl-dev -y

`libasound2-dev` and `alsa-utils` are ALSA audio packages, which belong to the local TTS and STT support, yet they are in the single prerequisite block with build tooling and OpenSSL headers. Git hooks are a prerequisite too, since `lefthook install` is step three and lefthook.yml sits at the root.

Seven PyPI extras, and a guardrails binding with no extra

The Python side ships one base package and a list of extras:

pip install autoagents-py                            # core + cloud LLM providers
pip install "autoagents-py[llamacpp]"               # + llama.cpp CPU
pip install "autoagents-py[llamacpp-cuda]"          # + llama.cpp CUDA
pip install "autoagents-py[llamacpp-metal]"         # + llama.cpp Metal (macOS)
pip install "autoagents-py[llamacpp-vulkan]"        # + llama.cpp Vulkan
pip install "autoagents-py[mistralrs]"              # + mistral-rs CPU
pip install "autoagents-py[mistralrs-cuda]"         # + mistral-rs CUDA
pip install "autoagents-py[mistralrs-metal]"        # + mistral-rs Metal

Every extra belongs to one of two backends, llama.cpp or mistral-rs, with accelerator variants for three of them. The Makefile, though, defines a third binding directory alongside those families, `GUARDRAILS_DIR := $(CURDIR)/bindings/python/autoagents-guardrails`, and guardrails is a listed crate in the workspace and a feature in its own right, with no extra documented for it. Two more version numbers appear in the development path, which creates a 3.12 virtual environment even though the prerequisites say Python 3.9 or newer, and pins maturin to `>=1.13.3,<2`. The build is then handed to two targets, `make python-bindings-build` and `make python-bindings-build-cuda`.

The Makefile hunts for a cdylib in two directories and fails loudly

The macro that installs a maturin-built extension explains its own failure, and it is the only place a build error message is written down:

	for dir in "$(1)/maturin" "$(1)/release"; do \
		for candidate in $$candidates; do \
			if [[ -f "$$dir/$$candidate" ]]; then \

It searches `maturin` and `release` under the binding directory, because which one holds the artifact depends on the maturin version. The candidate list is built from the platform-specific extension: `.so`, then `.dylib`, `.dll`, and a `lib_`-prefixed `.dll` for Windows, while the installed Python extension keeps its `.abi3.so` name. When nothing matches, the macro echoes `error: none of [$$candidates] found under $(1)/maturin or $(1)/release` to stderr and exits 1, after which `rm -f` clears the destination and `install -m 755` copies the artifact. The README explains why the build targets clean up first: stale editable-install extension artifacts would otherwise load out-of-date `.abi3.so` files from the source tree. The Makefile also forces `SHELL := bash` with `-eu -o pipefail`, auto-detects the interpreter from `.venv/bin/python`, and exports `UV_CACHE_DIR` and `PYTHONDONTWRITEBYTECODE := 1`.

cargo build --workspace also builds the examples

The workspace membership is what makes that build command expensive:

[workspace]
resolver = "2"

default-members = [
    "crates/autoagents-derive",
    "crates/autoagents-protocol",
    "crates/autoagents-llm",
    "crates/autoagents-core",
    "crates/autoagents-guardrails",
    "crates/autoagents-qdrant",
    "crates/autoagents-telemetry",
    "crates/autoagents",
    "crates/autoagents-toolkit",
]
members = ["crates/*", "examples/*", "bindings/python/*"]

Default members are nine crates, but the member list globs include `examples/*` and `bindings/python/*`, so a workspace build is not limited to the library. The examples directory alone holds around twenty named projects, among them guardrails, safe_local_agent, wasm_runner, wasm_tool, mcp, pipeline, rag_qdrant_agent, speech, telemetry, code_mode, coding_agent, design_patterns, image_chat, vector_store_in_memory, vector_store_qdrant, llamacpp_agent, llamacpp_agent_mtmd and mistral_rs. Two are excluded from the workspace, `examples/wasm_tool` and `crates/autoagents-test-utils`, along with two Python cache directories. The optional backends, `autoagents-mistral-rs`, `autoagents-llamacpp`, `autoagents-qdrant` and `autoagents-speech`, are declared as workspace dependencies with their own version numbers but are not in the default member list, and the Burn and Onnx backends live outside the workspace entirely.

Two license files, a dual license field, and one metadata value

The root directory carries `APACHE_LICENSE` and `MIT_LICENSE` as separate files, and the workspace package declaration says:

[workspace.package]
version = "0.4.0"
edition = "2024"
license = "MIT OR Apache-2.0"
description = "Agent Framework for Building Autonomous Agents"

The license field carried on the repository page is Apache-2.0 alone, so the page-level answer and the in-tree answer differ, and the choice between the two licenses is left to whoever consumes the crate. Every workspace dependency is pinned to `version = "0.4.0"` alongside its path, and that matches the newest release, v0.4.0, published on July 8, 2026, after v0.3.7 in March and v0.3.6, whose release title is the only one carrying a prefix. Eight translated READMEs sit beside the English one, covering Chinese, Japanese, Spanish, French, German, Korean and Brazilian Portuguese, under a note that translations may lag behind the English README. The last commit on the default branch is dated August 26, 2026. The visible example list ends mid-path, at a mistral-rs script name cut off after `mistral_`.

Editorial conclusion

AutoAgents fits a team that writes Rust and wants one typed surface across cloud and local models, with a capability matrix honest enough to plan against and a guardrails crate in the same workspace. It does not fit someone who needs one model and one script: the workspace pulls in the derive macros, the toolkit, telemetry, qdrant, speech and every example, and the Python path adds uv, maturin and a Make layer that hunts for a compiled artifact in two directories. Three things to check first: which providers you actually need, because xAI and Phind do no tool calls, MiniMax does no structured output, and four of the OpenAI-compatible providers reject PDFs outright; whether the audio system packages are acceptable on the build host, since libasound2-dev and alsa-utils are in the base apt line rather than behind a feature flag; and which license applies, because the root carries both APACHE_LICENSE and MIT_LICENSE while the workspace declares MIT OR Apache-2.0 and the license shown on the repository page is Apache-2.0 alone. The last release is v0.4.0 from July 8, 2026 and the last commit is dated August 26, 2026.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. liquidos-ai/AutoAgents on GitHub
3. Project website
4. README
5. Releases