MotleyAI's SLayer gives agents one metric definition instead of guessed SQL

What SLayer does

Text-to-SQL can go wrong without raising an error. As a dev.to post introducing the tool describes it, a model picks the wrong join or improvises its own idea of what counts as revenue, then returns a figure that looks plausible. SLayer, a semantic layer from MotleyAI, is built to remove that guesswork: it holds a single authoritative definition of each business metric, and agents query the metric rather than writing SQL against raw tables.

The mechanics are simple on the surface. A team defines a metric once — revenue, for example. When an agent then needs a total, an average, or the same figure shifted back a year, SLayer compiles the correct query for the underlying database from that shared definition. Every later answer is anchored to the same definition instead of whatever the model settles on for one particular prompt.

Six ways in for agents

According to the post, agents can reach SLayer through six interfaces: MCP, REST, a command-line tool, a Python client, Flight SQL, and a Postgres facade. The MCP support matters because it plugs the layer directly into the tool-calling pattern that agent frameworks increasingly rely on, while Flight SQL and the Postgres facade open it to tools that already speak those protocols. One layer can therefore serve both agent traffic and conventional query workflows.

Existing metric models carry over

SLayer can import configurations from dbt, Cube, and Ossie. Teams that have already modeled their metrics in one of those tools can bring those definitions across rather than restate them from scratch, which removes much of the setup cost. It also positions SLayer as a consumer of existing semantic models rather than a competing standard that everything must be rebuilt in.

Where the project stands

The post reports that version 1.8.2 shipped on 9 November 2026. The repository is written in Python and released under the MIT license, and had gathered 341 stars at the time of writing. Those numbers describe an early-stage project: an interesting direction with modest adoption so far, and the usual maturity caveats for anything heading toward production data infrastructure.

Why it matters

The silent failure mode of text-to-SQL is what makes it risky for agent workloads. Prompt-level fixes — better instructions, more schema context — can reduce errors but cannot guarantee them away, because the definition of "revenue" still lives in the model's interpretation of the moment. SLayer moves that definition into code and infrastructure: it is written once, reviewed once, and compiled consistently no matter which agent asks.

The approach also mirrors a pattern the data world has already accepted. Semantic layers solved a version of this problem for BI dashboards, where two charts showing "revenue" for the same period disagreed because they encoded different logic. As agents start answering questions in natural language, the same guarantees have to apply — arguably with higher stakes, because an agent's wrong number can flow directly into a decision or an automated action without a human ever seeing the query that produced it.

For teams already running dbt or Cube, the import path makes this cheap to evaluate. For anyone building text-to-SQL agents, SLayer is a useful reminder that the reliability problem may be better solved at the metric layer than at the prompt.