WrenAI

WrenAI (built by Canner) is an open-source GenBI (Generative BI) engine that gives AI agents a governed path from a plain-English question to trustworthy SQL, a chart, and a deployable dashboard. Rather than letting an LLM guess at your schema, WrenAI sits underneath the agent as a context layer: a version-controlled semantic model (MDL) that captures business definitions, approved joins, units, and examples, so every agent that touches the database inherits the same vetted understanding instead of re-learning it from scratch in a prompt.

The project is delivered as an agent-driven CLI (pip install wrenai) rather than a hosted app. Agents such as Claude Code, Cursor, or any MCP-capable client install a lightweight discovery stub (npx skills add Canner/WrenAI) that teaches them to pull workflow guides on demand — onboarding a warehouse, enriching business context, generating MDL, or building a GenBI app — so the guidance always matches the installed CLI version instead of drifting out of sync with static docs.

Under the hood, SQL planning and execution run through wren-core, a Rust engine built on Apache DataFusion that validates and rewrites queries against the MDL before they ever touch a warehouse (dry-plan validation, structured error codes, CTE rewriting). A WebAssembly build of that same engine, wren-core-wasm, lets deployed dashboards query static Parquet/DuckDB snapshots entirely client-side, so a generated GenBI app can be shipped to Vercel or Cloudflare Pages with zero backend.

WrenAI connects to 20+ data sources out of the box — BigQuery, Snowflake, PostgreSQL, MySQL, ClickHouse, Redshift, Databricks, Trino, Spark, and more — through a pluggable connector layer, and ships an MCP server so any MCP-aware agent can query through the same governed semantic layer instead of hitting the raw database directly.

What You Get

• A pip-installable CLI (wrenai) that scaffolds a project, connects a warehouse, builds a semantic model, and answers questions — no server or Docker stack required to get started.
• An agent discovery stub (npx skills add Canner/WrenAI) that teaches Claude Code, Cursor, Codex, Cline and other agents to pull versioned workflow guides on demand via wren skills get <name>.
• A Rust query engine (wren-core) built on Apache DataFusion that plans, validates, and rewrites SQL against the semantic model before execution, with dry-plan checks and structured error codes so failures are diagnosable, not silent.
• A browser-side WASM engine (wren-core-wasm) that lets a deployed GenBI dashboard query static Parquet/DuckDB snapshots client-side, so wren genbi deploy can ship a fully serverless dashboard to Vercel or Cloudflare Pages.
• 20+ first-class data source connectors — BigQuery, Snowflake, PostgreSQL, MySQL, ClickHouse, Redshift, Databricks, Trino, MSSQL, Spark, Athena, Oracle, Canner, and more — behind one connector interface.
• An MCP server (wren serve) exposing query, context, and knowledge tools so any MCP-capable agent (not just the bundled CLI skills) can query through the governed semantic layer.
• A versioned MDL semantic model plus a queryable memory store — approved definitions, joins, and prior natural-language-to-SQL pairs live as reviewable files (instructions.md, MDL JSON, knowledge/sql/*.md) instead of being buried in a prompt.
• Python SDKs for LangChain and Pydantic AI (wren-langchain, wren-pydantic) so the engine can be dropped into existing agent frameworks as a tool rather than requiring a rewrite.

Common Use Cases

• Data teams governing agent access to a warehouse — instead of giving every internal AI agent raw SQL credentials, teams point agents at WrenAI’s MDL so business definitions (“active user”, “gross margin”) stay consistent across every agent and dashboard.
• Coding agents building embedded analytics — a developer asks Claude Code or Cursor, already wired up via the WrenAI skill, to onboard a Postgres database and generate a first dashboard without hand-writing connector or charting code.
• Shipping shareable, serverless dashboards — wren genbi build + wren genbi deploy turn an agent’s SQL answer into a static, browser-side dashboard backed by wren-core-wasm, deployable to Vercel/Cloudflare with no backend to operate.
• Cross-warehouse semantic consistency — organizations running BigQuery, Snowflake, and Postgres side by side use one MDL so a metric is defined once and resolves correctly regardless of which connector answers the query.
• MCP-based BI access for any agent client — teams standardize on wren serve’s MCP server so Claude Desktop, custom agents, or internal tools all query the same governed layer rather than each maintaining its own SQL-generation logic.

Under The Hood

Architecture The repo is a modular monorepo split along language/runtime boundaries: a Python CLI package (core/wren, using Typer sub-apps such as ask_cli.py, context_cli.py, genbi/cli.py, memory/cli.py, profile_cli.py, serve_cli.py, all registered onto the root Typer app in cli.py) sits on top of a Rust semantic-SQL core (core/wren-core, exposed to Python via wren-core-py and to browsers via wren-core-wasm, alongside wren-core-base and wren-mdl). Execution traces from cli.py’s Typer commands into wren.engine.WrenEngine, a thin facade that loads a base64-encoded MDL manifest, runs SQL through wren.mdl.cte_rewriter.CTERewriter and wren.policy.validate_sql_policy, then dispatches to a per-datasource connector chosen by wren.connector.factory.get_connector — a dozen-plus connector modules (postgres.py, bigquery.py, snowflake.py, etc.) all implementing a shared base.py interface, so the connector layer is the only thing that changes per data source while MDL/policy is what changes if governance rules change. Project/profile discovery is deliberately decoupled from which MDL file --mdl points at (documented in code comments) to prevent a base64 override from silently bypassing a project’s pinned connection profile. The GenBI subsystem (genbi/composer.py, cli.py, verify.py) inverts the usual “tool builds the UI” pattern: the CLI never renders a dashboard itself, it hands the calling agent a hydrated build instruction combining a static template, live project facts, and the user’s prompt — so the dashboard-generation logic lives in whichever agent drives the CLI. What breaks if this abstraction changes is the whole agent-driven distribution model the project is built around.

Tech Stack The CLI is a Python 3.11+ package built with Typer, Pydantic v2, PyArrow, DuckDB, sqlglot (pinned >=29 for a renamed AST key), Loguru, OpenDAL/boto3 for storage, and python-dotenv for secret-safe profile expansion, packaged with Hatchling and published to PyPI as wrenai. The semantic-SQL core is a Rust Cargo workspace (wren-semantic-core, rust-version 1.78) built on Apache DataFusion 53 with nested/crypto/datetime/regex/unicode expression features, compiled additionally to Python bindings (wren-core-py) and to WebAssembly (wren-core-wasm) for in-browser query execution against static Parquet/DuckDB files. Data-source connectivity covers 20+ backends through optional extras (psycopg, mysqlclient, google-cloud-bigquery, snowflake-connector-python, clickhouse-connect, trino, pyodbc, databricks-sql-connector, redshift_connector, pyspark). A FastMCP-based server exposes the engine over the Model Context Protocol, and two SDK packages (wren-langchain, wren-pydantic) integrate it into LangChain and Pydantic AI agent stacks. CI is split by surface (Rust, core-py, WASM, each SDK) with dedicated publish workflows per package.

Code Quality The Python package carries an extensive pytest suite (dedicated files per connector plus unit tests for the engine, profiles, GenBI build/deploy, and skills CLI), and the Rust core has its own workspace tests, benchmarks, and a dedicated SQL-conformance test crate. Linting is enforced via Ruff on the Python side and rustfmt/taplo on the Rust side. Error handling is explicit and typed rather than swallowed: a structured WrenError carries error codes and phases, CLI commands catch exceptions and re-raise as controlled exits with a printed message, and profile loading raises named exceptions instead of returning None. Module boundaries are consistent (one *_cli.py per CLI concern, one module per connector implementing a shared interface), and CI is split per language/package so a failure in one surface doesn’t mask another. No dedicated Python type-checker (mypy/pyright) configuration was found alongside Ruff — the project leans on Pydantic models and the statically-typed Rust core rather than a Python-wide static type gate.

What Makes It Unique What differentiates WrenAI from a typical text-to-SQL chatbot or BI tool is the combination of a Git-reviewable semantic context layer (the MDL model plus instructions and memory files) built to be consumed by many different agents rather than living inside one vendor’s prompt, an agent-driven CLI that deliberately does not render its own UI — handing the connected coding agent a hydrated build instruction and letting the agent write and deploy the dashboard — and shipping the same Rust query-planning core to three targets (native Python, WebAssembly, and the CLI’s own engine) so a generated dashboard can run governed SQL entirely client-side against static snapshots with zero backend. Dry-plan validation and a documented hard rule against inlining warehouse credentials into statically-deployed apps show governance was designed in rather than bolted on. The underlying pieces (DataFusion, MCP, semantic layers) exist elsewhere, but the agent-first distribution model and browser-executable core are not standard patterns in the BI space.

Self-Hosting

Licensing Model WrenAI is multi-licensed by path within a single repository (see the root LICENSE file): core/, sdk/, skills/, examples/, and root files are Apache License 2.0; docs/ is CC BY 4.0. There is a pre-emptive LICENSE-AGPL-3.0 file in the repo for AGPL-3.0-only modules the project says it may introduce in the future, but as of this writing no path in the repository is mapped to that license — everything shippable in this codebase today is Apache-2.0 or CC BY 4.0.

Self-Hosting Restrictions No license checks, feature flags, or gated code paths were found anywhere in the cloned source (core/, sdk/, skills/). The CLI, semantic engine, connectors, MCP server, and GenBI build/deploy commands all run fully self-hosted with no license key.

Enterprise Features The company’s hosted product site (getwren.ai/pricing) advertises separate Cloud plans (Free, Essential, Enterprise Cloud) and a self-hosted “Enterprise Plus” tier with session-based licensing, SSO/SCIM, air-gapped deployment, row/column-level access controls, and dedicated support. Those tiers apply to Wren AI’s commercial hosted/managed offerings and the legacy WrenAI GenBI Classic product (preserved on the legacy/v1 branch) — none of that gating exists in the current open-source CLI/core/sdk code in this repository.

Cloud vs Self-Hosted The OSS CLI in this repo is a fully self-hosted, agent-driven tool with no cloud dependency; Wren AI separately operates a managed Cloud product with its own pricing, which is outside the scope of this repository.

License Key Required No. Nothing in the cloned repository checks for or requires a license key.