Wren AI 0.18.0: Project-Scoped Agents, Managed MCP

1. The same rules for delegated and direct queries

This version adds wren serve agent and wren serve mcp --service-config. In the agent service, an external agent delegates a question, and an internal worker reads project information and writes SQL. With managed MCP, external tools submit SQL directly. Both paths execute read-only queries after policy checks.

This approach manages both project reference material and the execution interface. Materials shown to external agents can differ from those used by internal workers to build queries. Both services are optional. Normal query execution and existing unmanaged MCP behavior remain unchanged.

To use the services, specify the project, service configuration, agent profile, runtime, and compiler paths. The runtime runs the program, while the compiler prepares code for execution. Register the service in the external client's MCP connection. Managed MCP uses this setup too. The source example below includes policies, connection details, a worker model, metadata to expose, and execution limits. Metadata describes the structure and properties of the data.

config_version: 2
caller: local-planner
project_id: synthetic-orders
policy: policy.cedar
connection: {datasource: local_file, url: ../data, format: duckdb}   # optional; see below
metadata_selection: []
private_model: {id: nvidia/nemotron-3.5-lightning-30b-a3b, base_url: https://integrate.api.nvidia.com/v1, credential_env: NVIDIA_INFERENCE_API_KEY}
execution: {deadline_ms: 120000}

Administrators can choose presets: predefined settings that combine document exposure and result evidence visibility. The example provides four presets. By default, external agents see no metadata and receive the narrowest scope of result evidence.

The default connection uses standard input and output. The agent service also supports HTTP connections on the same machine using a local token. Managed MCP connects through standard input and output.

2. Project documents become query-checking criteria

At startup, the service reads the project's data structures and relationships, knowledge documents, saved queries, and dashboards. It builds context, or background information for query writing, and dependencies, or references between elements. Policies limit exported metadata, while internal workers use project context to construct queries.

On managed paths, SQL is checked against model and column restrictions and the project's declared baseline rules before execution. Execution is denied even when the checker cannot determine whether a query is allowed. If a project declares rules for excluding test orders or converting currencies, each query is checked for compliance. The agent path also structurally checks whether exchange-rate table joins follow declared rules.

Columns to block are declared in the project rules file. They are excluded from metadata, and SQL reading them is rejected during authorization, which checks permissions. Results include evidence such as the data read and rules applied, allowing the planner to make decisions within the permitted scope.

3. Exposure control comes with configuration management

This design fixes rules and exposure scope for each project. It blocks external agents' queries before they violate internal criteria and records the basis for decisions. Operators must manage project settings, policies, and the private worker runtime, and decide which documents to expose. Configuring the worker model and connection details is also part of adopting the service.

If saving an audit record fails, the service stops controlled result delivery. Operators must restore the storage location and restart the service. This ties audit records to operations through the result-export stage.

The checks do not fully prove actual data values or the effects of joins that multiply rows. Guarantees for views, virtual tables that treat saved queries as tables, also depend on their authors' declarations. Managed agent queries reject views that read other views, so project view dependencies need review before adoption.

4. Released features and local test results

Wren AI released 0.18.0 on November 10, 2026. According to the company, the feature pull request reported 3,572 passes and 6 skips in local deterministic runtime tests of the final code. Deterministic tests produce the same results for the same inputs. These figures describe the pass status of a defined local runtime test suite.

Wren AI 0.18.0 uses project context and rules as boundaries for external agents' queries, delivering controlled data use through service configuration.