Rig
Build modular, scalable LLM applications and agent workflows in Rust.
Optional features, disabled dependency defaults, deliberate CI secret isolation, and explicit release permissions show solid least-privilege awareness; cassettes are redacted and model artifacts are pinned by commit, size, and hash. Deductions apply because the example reads credentials from the environment without documenting runtime retention or credential lifecycle, and the framework provides no general user-confirmation gate, external-effect policy, or transactional rollback. Temporary-download cleanup and serializable AgentRun state are useful but are not effect recovery. Repository, copyright, and licensing attribution are clear, while the enterprise publisher identity remains unknown.
The README, Cargo feature mappings, CI commentary, and cassette tests are unusually consistent about architecture, features, and test strategy, justifying full self-consistency. Version constraints, locked builds, offline replay, retries, and verified downloads improve dependency availability, but many cloud services and third-party packages remain externally dependent. Native-only checks and download scripts emit actionable failures, although the supplied files do not show equally complete diagnostics for every provider and runtime path.
The evidence covers basic LLM use, streaming, multi-turn agents, tools, embeddings, media, and vector stores, but offers limited audience segmentation and deployment-selection guidance. The rig-core/rig-agent split, feature gates, WASM/WASI matrix, and rmcp restriction define capability boundaries thoroughly. Typed tool schemas and multi-step cassettes show precise orchestration, but actual triggering policy remains application- and model-defined. Browser-WASM coverage, native restrictions, TLS choices, Tokio requirements, and per-package CI checks provide strong environment-fit evidence.
The README has clear navigation, architecture, integration tables, documentation entry points, and examples. Installation and Tokio notes support initial use, but credential setup, production deployment, and provider-specific configuration are not fully covered in the supplied material. The facade stabilizes common paths, while the explicit breaking-change warning prevents a full naming-stability score. Examples, test locations, and cassette guidance are extensive. WASI, rmcp, and breaking-change limitations are disclosed, though no comprehensive limitations catalog is shown. The MIT text matches manifest metadata, earning full license credit. Versions and automated releases are evident, but an actual changelog or migration history is absent. Copyright ownership, repository, and issue paths identify a maintenance route, although publisher registry provenance is unverified.
The example and cassettes demonstrate directly usable prose and multi-step tool results, but they do not establish structured-output quality, production result validation, or output contracts across broad scenarios. A unified abstraction over more than 20 model providers, numerous vector stores, and portable runtimes offers well-supported marginal value. Feature gating and low-boilerplate examples reduce integration cost, but there are no comparative measurements for performance, provider expense, binary size, or operational burden.
Core architecture and feature claims are traceable to Cargo features, workflows, and cassettes; deductions apply because the user list and some scale or production claims are primarily README assertions. README, manifest, CI, and cassette evidence strongly corroborate feature boundaries, offline testing, and multi-step tool use, justifying full cross-source corroboration. Warnings, support boundaries, and test strategy are generally distinguished from facts, but marketing language and third-party adoption claims are not consistently backed by repository-local proof.
- The framework can connect applications to model providers, databases, and user-defined tools; deployers should add per-action authorization, confirmation for external writes, auditing, and rollback controls.
- Provider clients read credentials from the environment; use narrowly scoped keys, prevent their inclusion in prompts, logs, telemetry, or cassettes, and review each provider's retention policy.
- The README explicitly anticipates breaking changes; pin versions and review migrations, feature defaults, and facade forwarding before upgrades.
- The dependency and optional-integration surface is large; run vulnerability, license, and supply-chain checks against the exact enabled feature set.
- Cassettes contain request and response bodies; any new or re-recorded fixtures must continue scrubbing secrets, personal data, and provider identifiers.
What does this agent do, and when should you use it?
Rig is a Rust library for building modular, scalable LLM applications rather than a ready-to-deploy chatbot. Its architecture separates `rig-core`, which defines provider-neutral messages, models, tools, memory, and vector-store contracts, from `rig-agent`, which supplies the classic builder, prompt and streaming traits, typed hooks, contextual tools, extraction, and a serializable `AgentRun` state machine. The root `rig` facade re-exports both layers and exposes companion database, vector-store, local-model, and cloud integrations through Cargo features. Applications can run completion, embedding, multi-turn prompting, and streaming workflows, with interfaces covering transcription, audio generation, and image generation model capabilities. The portable core and classic runtime support browser `wasm32-unknown-unknown`, while WASI is unsupported and `rmcp` is native-only. Adopters must still write the surrounding Rust application, configure a model provider, and own its build and deployment.
A developer creates a provider client from rig::providers, builds an agent with calls such as client.agent(...).preamble(...).build(), and invokes Agent::prompt(...).await to obtain a response. rig-agent handles multi-turn prompting, streaming, typed hooks, contextual tools, extraction, and serializable AgentRun execution state, while rig-core supplies the message, completion-model, portable-tool, memory, and vector-store contracts. The model layer supports completion and embedding workflows and exposes model capabilities for transcription, audio generation, and image generation. Feature-gated companion crates connect applications to backends including LanceDB, Milvus, MongoDB, Neo4j, PostgreSQL, Qdrant, SQLite, and SurrealDB, as well as components such as FastEmbed, Candle, Vertex AI, and Bedrock. The outputs become responses, streams, extracted values, or run state inside the adopter's Rust program; Rig itself does not provide a hosted end-user service.
- A Rust backend team wants one interface for multiple model providers instead of maintaining separate completion and embedding adapters.
- An agent application developer needs multi-turn context, streamed output, contextual tools, typed hooks, and serializable execution state.
- A retrieval application team needs to connect embedding workflows to PostgreSQL, Qdrant, LanceDB, Milvus, MongoDB, or another documented storage integration.
- A browser-focused Rust team wants the portable core or classic runtime on
wasm32-unknown-unknownand can work within the WASI and native-only component restrictions. - A Rust product needs to organize text completion, transcription, audio generation, and image generation model calls behind one framework.
- An engineering team wants model-call telemetry aligned with the GenAI Semantic Convention.
What are this agent's strengths and limitations?
- More than 20 model providers sit behind a unified interface that covers both completion and embedding workflows, reducing repeated provider adapter work in Rust applications.
- The
rig-coreandrig-agentsplit lets projects adopt only provider-level contracts or add the complete orchestration layer, while the root facade preserves familiar imports. - More than 10 vector-store integrations are available, with one Cargo feature per companion integration to keep dependency selection explicit.
- The classic runtime includes concrete orchestration primitives: multi-turn streaming, typed hooks, contextual tools, extraction, and a serializable
AgentRunstate machine. - The portable core and classic runtime explicitly support browser
wasm32-unknown-unknown, and the library supports the GenAI Semantic Convention.
- The project explicitly warns that forthcoming releases will contain breaking changes, creating version-pinning, testing, and migration work for adopters.
- Rig is a library rather than a hosted product, so teams must implement credential management, deployment, error handling, application entry points, and any user interface.
- Portability has documented limits: WASI is unsupported,
rmcpis native-only, and not every component can be moved unchanged across targets. - The example assumes an asynchronous Rust stack with correctly selected Tokio features, and each application must choose and configure its own model provider.
- The supplied material demonstrates a basic OpenAI text prompt but does not document a production deployment topology, retry policy, cost controls, or complete configuration examples for every provider.
How do you install or deploy this agent?
Install Rust and Cargo, then run cargo add rig in a Rust project. Use cargo add rig-core instead when only the core provider abstractions are needed. Enable companion integrations in Cargo.toml when required; the documented example is rig = { version = "0.36.0", features = ["lancedb", "fastembed"] }. The asynchronous example also requires Tokio, installable with cargo add tokio --features macros,rt-multi-thread, plus anyhow for its shown return type. Before running the OpenAI example, configure the OpenAI credentials expected by openai::Client::from_env(); the supplied source does not name the exact environment variables.
How do you use this agent?
In an asynchronous Rust program, import use rig::prelude::*; and use rig::providers::openai;, then create a client with openai::Client::from_env()?. Build an agent with client.agent(openai::GPT_5_2).preamble("You are a comedian here to entertain the user using humour and jokes.").build(). Invoke it with comedian_agent.prompt("Entertain me!").await? and print the returned value. The entry point may use #[tokio::main] async fn main() -> Result<(), anyhow::Error>; Tokio must have macros and rt-multi-thread, or full, enabled. For storage or model extensions, enable the matching rig feature and use its documented root path, such as rig::lancedb or rig::fastembed.
How does this agent compare with similar options?
Use the root rig package when an application wants feature-gated access to rig-agent and companion model, database, or vector-store crates. Use rig-core directly when only provider-neutral messages, completion models, portable tools, memory, and vector-store contracts are required. These are complementary layers rather than competing products: rig is the facade, while rig-core is the smaller foundation.
FAQ
Does Rig host or deploy the agent?
What credentials are required for the example?
openai::Client::from_env(), so valid OpenAI API credentials must be available in the environment. The supplied source does not specify the exact variable names. Other providers require their own integration configuration, which is not detailed here.Can it run in a browser or on WASI?
wasm32-unknown-unknown. WASI is explicitly unsupported, and rmcp is native-only.Must I adopt the complete agent runtime?
rig-core for provider abstractions. Use the default rig-agent layer or root rig facade when the classic builder, streaming prompts, hooks, contextual tools, extraction, and AgentRun state machine are needed.