SLayer (MotleyAI)

An embeddable semantic layer that sits between a warehouse and the things querying it, built by MotleyAI on the premise that agents need a different shape of semantic layer than BI tools did. MIT, Python, 158★ / 22 forks, created 2026-03-17, last pushed 2026-08-30, with 2,035 commits on main. Ships on PyPI as motley-slayer; docs at docs.motley.ai/slayer.

It is the spoke's second source on the layer above the engine, and the first on the read side of it. jitsu holds the write side — an event pipeline that lands data in whichever warehouse you name, treating the engines as interchangeable endpoints. SLayer treats them as interchangeable in the same way and from the opposite direction: it stores nothing, is read-only, and compiles a query expression into SQL that duckdb, clickhouse, snowflake or a peer executes. Between the two, the engines this spoke is built around appear as a substitutable middle — which is a claim about the market worth watching rather than one either source argues.

T1 for what the project is — architecture, interfaces, the expression grammar. It publishes no benchmark and no evaluation, so nothing here says whether the approach produces better answers than the alternative it argues against.

The argument it makes

"Traditionally, semantic layers were a part of the BI stack, where every metric and its aggregation had to be predefined. Agents need more flexibility because users ask questions that involve metric combinations (like ratios), transforms (like time shifts), or different aggregations of the same metric (like average instead of sum)."

The classical semantic layer binds a metric to an aggregation at definition time: monthly revenue is a defined object. A person driving a dashboard picks from the defined objects, so the constraint is invisible. An agent answering an arbitrary question hits it immediately, because the question it was asked names a combination nobody predefined.

SLayer's answer is to define the column once and let the caller compose the aggregation at query time through an expression grammar: revenue:sum, revenue:avg, revenue:sum / *:count, time_shift(revenue:sum, -1, 'year'), plus multi-stage queries. Aggregation moves from definition time to call time; governance stays at definition time.

That is the interesting move, and it is worth stating plainly what it trades. A predefined metric is a promise: everyone who asks for monthly revenue gets the same number by construction. An expression grammar returns that composition responsibility to the caller, and the caller here is a language model. What is preserved is that the model composes from governed columns in a constrained grammar rather than writing free SQL; what is given up is the guarantee that two agents asking the same business question compose it the same way. Nothing in the repository measures which way that lands.

Where it sits against text-to-SQL

The default agent-analytics approach is to hand the model a schema and let it write SQL. SLayer is the argument against that, without saying so: the model gets a search tool for discovery, a memory store for business context, and an expression language, and the SQL is generated by the layer instead. The README's one piece of evidence is a screenshot of LLM-written SQL beside the equivalent SLayer query for "monthly revenue by store, with month-over-month % change" — an illustration, not a measurement, and it is the only comparison offered. Corrected 2026-10-01: the README illustration was never the only comparison. Motley's own blog (Egor Kraev, 2026-06-22) reports BIRD-INTERACT mini-interact runs with Opus 4.7: 71.7% with raw SQL and 75.3% with SLayer against the original gold answers (79.0% / 83.7% against Motley's re-annotated gold), and says the agent harness mattered more than the layer. And PR #459, merged 2026-10-01, adds a 359-probe suite against Malloy, Cube Core and MetricFlow (SLayer 209 passes, Malloy 79, Cube 55, MetricFlow 42, on probes chosen by Motley). Both are the vendor measuring itself; no third party has run either.

The governance half is the more checkable claim. Connectivity is read-only, row-level security is enforced at the layer, and the datasource password is read at init time and, per the README, "not saved to disk nor exposed to Claude." So the layer is also a blast-radius control on an agent with database access — the part of this that would be worth having even if the expression grammar were not.

Interfaces, and the interop position

Six ways in: MCP, REST, CLI, a Python client, Arrow Flight SQL, and a Postgres-wire SQL API (a "pg facade"). The last two matter for adoption rather than design — an existing BI tool that speaks Postgres or Flight SQL can point at SLayer without knowing it is not a database. The MCP server is the agent path; the quickstart is literally claude mcp add slayer -- slayer mcp --demo against a bundled Jaffle Shop dataset.

It also imports definitions from dbt, Cube, and OSI (Open Semantic Interchange) configs — positioning as a layer you can move to rather than a stack you must adopt. OSI is the first standards-shaped thing to appear in this spoke's tooling corner; nothing here evaluates it.

Maintenance against attention

2,035 commits, 158 stars, 4 open issues. That ratio is the inverse of what this hub usually finds in first-party repositories, and it is worth one line because the corpus keeps meeting the opposite case — packs with thousands of stars and a single push. Sustained work with little attention says nothing about quality either, but it does mean the artifact is being maintained by someone who is not being rewarded in stars for it. Both numbers are a 2026-08-31 snapshot.

Cross-spoke context — ../agentic-tooling-wiki

The agent-facing half belongs there and is not paged here: the search → inspect → query flow the README names as "the common agentic" pattern, the memory store as a place to pin business context, and the MCP server as the delivery mechanism. That spoke owns agent machinery; this one owns the query layer. The seam is real — the whole design premise is a claim about what agents need — so the argument above is recorded here and the mechanism cross-links there.

Recorded weaknesses

Nothing run, nothing measured. No benchmark, no accuracy comparison against text-to-SQL, no latency or translation-overhead numbers, no third-party review. The claim that agents hit the predefined-metric wall is asserted from experience and is plausible, but it is a design rationale rather than a finding. Star, fork and commit counts are volatile. Supported databases are listed only in the docs, and no coverage claim here has been checked against the engines this spoke holds.

Related

semantic-layer · motleyai · analytical-databases · duckdb · clickhouse · snowflake · tinybird · model-context-protocol · synthesis