rig-agent

rig-agent contains Rig's classic agent runtime: builders, the serializable sans-I/O run state, blocking and streaming drivers, typed hooks, contextual tools, extraction, and runtime integrations.

Most applications should use the root rig facade, where this runtime remains enabled by default. Low-level provider and backend contracts live in rig-core.

Direct users import construction and prompting explicitly:

use rig_agent::prelude::*;
use rig_core::{client::ProviderClient, providers::openai};

let client = openai::Client::from_env()?;
let agent = client.agent(openai::GPT_5_2).build();
let answer = agent.prompt("Explain ownership briefly.").await?;

Portable tools implement rig_core::tool::PortableTool and work in both runtimes. Classic tools that need mutable per-call state implement rig_agent::tool::Tool and receive &mut ToolContext.

Target support

Building for wasm32-unknown-unknown is the entire opt-in — there are no wasm feature flags anywhere in the workspace. rig-core relaxes its WasmCompat* bounds from the target alone.

Wasm gates name a target_os (all(target_arch = "wasm32", target_os = "unknown")) rather than a bare target_arch = "wasm32", because the latter also matches WASI, which has no JS host. WASI itself does not build: rig-core depends unconditionally on reqwest, which pulls hyper/socket2 and a tokio feature set WASI rejects. Supporting it would mean making reqwest optional and adding a wasi:http client behind rig_core::http_client — a project, not a cfg fix.

rmcp is native-only. rmcp's ClientHandler is declared Sized + Send + Sync + 'static unconditionally — its local feature relaxes the future bounds but not the handler itself — while this crate's handler owns a tool registry whose Arc<dyn ErasedTool> is deliberately neither Send nor Sync on wasm. Enabling rmcp on a wasm target fails with a single explanatory compile_error! rather than a wall of trait errors.