slayer vs WrenAI
Embeddable semantic layer for AI agents: define metrics once, compose them with expressions and time shifts, row-level security and read-only SQL, over MCP, REST, CLI, Python or a Postgres facade. — versus — Open-source GenBI engine: agents write governed SQL and deploy shareable dashboards over 22+ data sources, grounded in a Git-friendly context layer (MDL semantics, definitions, memory).
Same goal, agents answering with governed SQL instead of guesses: wrenai is a full GenBI app with dashboards and MDL semantics, SLayer the embeddable semantic engine alone.
| slayer | WrenAI | |
|---|---|---|
| Stars | 227 | 18k |
| Forks | 31 | 2.0k |
| Language | Python | Python |
| License | MIT | NOASSERTION |
| Last activity | today | 3 days ago |
| Topics | data | agents |
| Curated connections | 5 | 5 |
slayer — the curator's take
Reach for SLayer when agents keep writing plausible-but-wrong SQL against your warehouse: define columns and metrics once, and agents compose them (ratios, time shifts, alternate aggregations, multi-stage queries) through a search, inspect, query flow instead of free-hand joins, with read-only connections and row-level security handled for them. It imports dbt and Cube definitions, embeds as a Python library, and speaks MCP, REST, Flight SQL and the Postgres wire protocol, so BI tools hit the same definitions. It is the core of Motley's product and still young (a few hundred stars, six contributors). Skip it if you want dashboards out of the box (wrenai) or a layer that builds itself from your existing BI assets (ktx).
WrenAI — the curator's take
The strongest open answer to 'my agent writes confidently wrong SQL': business definitions, approved joins and past queries live in reviewable files, not prompts, and dry-plan validation catches errors before execution. Agent-driven by design (skills + CLI, works through Claude Code/Cursor). Skip for one-off charts from a CSV — the context layer is the point, and it takes real setup.