WrenAI GenBI
Give AI agents governed business context to produce SQL, charts, and deployable dashboards.
Per-dimension scores and reasoning
Evidence shows: README explicitly states that row/column-level security (RLS/CLS) and access control are commercial features, not included in OSS, limiting least privilege defaults. User confirmation: CLI workflow guides (e.g., onboarding) are agent-driven but do not explicitly require user confirmation for critical actions. Data flow transparency: README describes data flow (query, deploy to Vercel/Cloudflare) but lacks detail on data handling/storage. Sensitive data handling: RLS/CLS implemented in tests but not in OSS; no mention of encryption or masking. Dependency security: SECURITY.md provides vulnerability reporting but no dependency scanning or known vulnerability mitigation. External effects: Deployment to external platforms requires user authorization but permissions scope unclear. Rollback: MDL and context are Git-friendly, supporting version control, but no explicit rollback mechanism. Source attribution: MDL and instruction files are version-controlled but no explicit source tracking. Deductions: OSS lacks RLS/CLS, user confirmation and permission scope unclear, dependency security info insufficient.
Evidence shows: README and test files (e.g., test_cube.py, test_modeling_core.py) demonstrate internal consistency, with tests covering various scenarios. Dependency availability: README mentions 22+ data sources but no availability guarantees or failover mechanisms. Failure messages: Tests verify error messages (e.g., 'Permission Denied') but no user-friendly error handling documentation. Deductions: Dependency availability not explicit, failure messages only partially covered.
Evidence shows: README clearly identifies target audience (AI agent builders) and scenarios (text-to-SQL, dashboard deployment). Capability boundaries: README explicitly lists OSS vs commercial features (e.g., RLS/CLS) and 'Skip Wren if' scenarios. Trigger precision: CLI commands and skills (e.g., wren skills get onboarding) provide clear triggers. Environment fit: Supports multiple data sources and deployment platforms (Vercel/Cloudflare) but lacks detailed environment requirements. Deductions: Environment requirements not detailed, but overall adaptability good.
Evidence shows: README provides clear project structure (core/, sdk/, skills/ etc.), good information architecture. Install notes: Provides pip install commands and extras. Naming stability: README mentions 'GenBI' name change and legacy branch, but no version naming conventions. Examples and FAQ: README includes FAQ and quickstart examples. Known limitations: README explicitly lists OSS vs commercial boundaries but not all known limitations. License: LICENSE file details multi-licensing (Apache-2.0, CC-BY-4.0, AGPL-3.0) but README claims Apache-2.0, inconsistency. Versioning/changelog: README mentions releases and changes but no detailed changelog. Maintenance responsibility: SECURITY.md and contributing guide clarify maintenance. Deductions: License inconsistency, versioning/changelog not detailed.
Evidence shows: README describes outputs (SQL, dashboards) and deployment flow, output usability good. Marginal value: Compared to raw LLM agents and traditional BI tools, provides governance and context layer, value clear. Cost-benefit: Open-source free, but commercial features require payment; cost-benefit not analyzed in detail. Deductions: Cost-benefit not detailed, but overall value clear.
Evidence shows: Claims in README (e.g., 22+ data sources) lack specific evidence, but test files verify some functionality. Cross-source corroboration: README and test files corroborate each other, but no external verification. Fact-inference separation: README distinguishes OSS and commercial features but does not explicitly separate facts and inferences. Deductions: Claims lack specific evidence, cross-source corroboration limited.
- OSS version does not include row/column-level security (RLS/CLS) and access control; these are commercial features, so data protection must be considered when deploying.
- README claims Apache-2.0 license, but LICENSE file shows multi-licensing (including potential AGPL-3.0), inconsistency exists; confirm before use.
- Dependency security information is insufficient; no mention of dependency scanning or known vulnerability mitigation; recommend self-audit.
What does this agent do, and when should you use it?
WrenAI is an open-source generative BI engine for AI agents, spanning natural-language questions, SQL, charts, and shareable dashboards. Its context layer combines MDL semantic models with versioned instructions.md and queries.yml files plus a local LanceDB memory index for business definitions, examples, and query recall. The core tree includes a Rust semantic engine built on Apache DataFusion, Python bindings, a Python SDK and CLI, and the browser-side wren-core-wasm build. Agents can run MDL-mediated queries with wren query and use the GenBI workflow to build browser-side dashboards for deployment to the user’s Vercel or Cloudflare Pages account. It is a fit for teams that want governed, Git-friendly business context behind their existing agents, rather than a one-off chart from a CSV.
After installing wrenai, an agent can fetch the setup workflow with wren skills get onboarding, check the environment, create a connection profile, scaffold a project, and run an initial query. It works from MDL definitions for models, columns, relationships, views, cubes, metrics, and row- and column-level access control, alongside instructions.md, queries.yml, and a LanceDB memory index. Agents can shape questions with wren ask "<question>" --guided or --direct, or execute SQL through the MDL layer with wren query --sql '...'; the repository also names schema-aware retrieval, MDL planning, dry-plan validation, structured errors, functions, and row limits. For dashboard delivery, an agent fetches wren skills get genbi, builds a browser-side GenBI app powered by wren-core-wasm, previews it locally, and deploys it to the user’s Vercel or Cloudflare Pages account.
- A data team using Codex, Claude Code, or another connected agent needs answers to quarterly sales questions based on approved Postgres business definitions.
- A warehouse team on BigQuery, Snowflake, ClickHouse, or Databricks wants approved metrics, joins, and enum meanings maintained as versioned context.
- An analytics engineering team wants an agent to turn a validated query into an interactive, filterable dashboard and publish it on its own Vercel or Cloudflare Pages account.
- A company whose business logic is scattered across documents, wikis, and chat threads wants to encode that knowledge in MDL, instructions.md, queries.yml, and memory records.
- A Python team building a data assistant with LangChain or LangGraph wants to use the repository’s wren-langchain reference SDK integration.
What are this agent's strengths and limitations?
- It keeps MDL, instructions.md, queries.yml, and memory as reviewable, version-controlled business context instead of relying only on schemas or prompts.
- It covers governed SQL, charts, and dashboard deployment; dashboards run browser-side with wren-core-wasm and can be published to the user’s own Vercel or Cloudflare Pages account.
- The repository names a 22+ data-source engine based on Apache DataFusion, alongside a Python CLI, Python bindings, and a wren-langchain reference integration.
- It documents concrete governance primitives including dry-plan validation, access controls, row limits, and structured errors.
- A usable deployment still needs a data-source connection profile; the supplied material does not provide credential formats, connection parameters, or a complete non-agent configuration path.
- Good results depend on maintaining MDL, business instructions, query examples, and memory, which creates an ongoing modeling and governance workload.
- Dashboard delivery is bounded by the user’s own Vercel or Cloudflare Pages account rather than a repository-described integrated hosting service.
- The former Docker chat-first product now lives on legacy/v1 and is stated to receive no new features or security fixes, so it should not be treated as the maintained path.
How do you install or deploy this agent?
Use an environment with shell access, network access, and connectivity to a target data source:
pip install wrenaiFor Postgres and memory support:
pip install "wrenai[postgres,memory]"Then install the AI-client discovery stub:
npx skills add Canner/WrenAIThe supplied material says this command auto-detects Claude Code, Cursor, Cline, Codex, and similar clients. The required data-source credential fields and connection parameters are not specified in the supplied material; create the connection profile through the onboarding workflow.
How do you use this agent?
From a project directory, begin with:
wren skills get onboardingHave an AI client with the discovery stub follow that workflow to set up the database and run an initial query. To add business context, run:
wren skills get enrich-contextFor routine querying, use:
wren query --sql '...'Or have the agent use:
wren ask "Who are our top 10 customers by sales this quarter?" --guidedFor dashboards, run wren skills get genbi and have the agent generate, preview, and deploy the browser-side app. Deployment requires the user’s own Vercel or Cloudflare Pages account.
How does this agent compare with similar options?
The repository contrasts WrenAI with raw LLM agents, traditional BI tools, and bare semantic layers. Its stated distinction is governed SQL generation from external agents plus agent-driven dashboard deployment, whereas traditional BI dashboarding is described as manual and inside the BI tool.