Motley

Cube, Malloy, MetricFlow and SLayer, side by side. The landscape of semantic layers can be confusing in the beginning - even if one just looks at the open source ones, where not only the docs, but also the source code is there to inspect. Different ones highlight different features, and claims can be hard to compare. We wrote the most extensive comparison of open sources semantic layers, validating each capability with code. Find it here: motley.ai/blog-posts/four-op…

User: "Show me revenue." Agent: "Gross, net, recognized, booked or vibes-based?"

How do you know if your semantic layer is bad? Users' AI agents already know, but they have no way to tell you. Every time an agent has to invent a metric definition or can't find the data it's looking for, it's a signal that gets lost. Motley now captures it. Every question a user asked, every step their agent took, and the agent's own report: answered, missing data, unclear docs, wrong result. Look at those and fix the causes (an agent can help with that too), and the semantic layer quickly gets good at even the most complex questions a team and its users have. Full post: motley.ai/blog-posts/how-do-…

Between raw data and a useful answer, there should be a semantic layer

Architectural principles for a codebase are all well and good, but how do you make them stick? A well-structured codebase must fulfill two top-down principles: modularity and faithful representation of the big-picture intent. How do coding agents get made to observe both of these? How can they even be represented formally? In the SLayer repo, modularity is modeled by a LikeC4 hierarchical model, with its nodes mapped to the Python modules, and the import structure implied by it hard-enforced by CI checks. To represent the intent of the codebase, in a hierarchical manner, the LikeC4 nodes each correspond to arc42 documents that spell out the normative principles the respective submodule must observe. These are read by the agent during each PR phase, and treated like tests, each modification needs explicit approval. These high-level principles and constraints combine with the local optimization of the four-stage PR flow, to result in code that is sound both locally as well as architecturally. If this approach resonates, let us know whether the skills and scripts should be factored out into a reusable repo, happy to do that if there's interest! Coding agent sceptics: what's missing here? Detailed post: dev.to/egor_kraev_0e262330fb… SLayer repo: github.com/MotleyAI/slayer

What do DuckDB and SLayer have in common? They are both lightweight, and can be run both embedded and via a CLI (as well as MCP and other ways ;) ), no server to run if you don't want to, no warehouse to provision. DuckDB can read a file straight off a URL over httpfs; SLayer can auto-ingest a schema during datasource setup, and then turns its simple yet powerful query syntax into the correct SQL. Put them together and a semantic layer over a remote dataset is a handful of lines. To show just how simple and powerful that pattern is, example notebooks have been put together, one for CLI, one for Python. Each notebook shows, from scratch, how to define a view over a remote file in DuckDB, then to connect SLayer to that view, and to execute a deceptively simple query, containing: • A dimension computed from an aggregate, group each month warm or cool by its average high temperature, a CASE WHEN temp_max:avg(partition_by=date) … band used as a grouping dimension • A ranking transform in a measure, rank(precipitation:sum) to order the months by rainfall, one of SLayer's query-time transforms. Both of these are defined at query time, showing how SLayer removes the need to pre-configure every little thing you want to query. Why use SLayer at all, instead of direct SQL? The final cell of each notebook shows the SQL corresponding to that "simple" query json. Judge for yourself which one is easier to read, and which one an agent is more likely to generate correctly, time after time. CLI: github.com/MotleyAI/slayer/b… Python: github.com/MotleyAI/slayer/b… SLayer repo: github.com/MotleyAI/slayer

Once semantic layer configs become a commodity, query-time behavior is the whole game, and most incumbents don't do it well. Apache Ossie will make moving definitions between semantic layers free. That's a welcome shift. What's left is how the layer behaves at query time, and the old guard was built for a dichotomy that's ending: either the same queries, over and over, rewarding cached pre-aggregations and static configs, or freestyle SQL. Neither option works well for agents. Two properties now decide whether a semantic layer is any use to one: Expressiveness. An agent needing a ratio of two metrics, or a time-shifted version of one, maybe joining several datasets, can't stop to edit a model config and wait seconds for it to propagate. It should be able to describe what it wants and have the SL engine generate the CTEs, joins, and dialect-correct SQL on the spot. Discoverability. Governed metrics are worthless if an agent can't find the right ones among thousands of tables, or surface the business rule that spans several metrics at once. SLayer addresses this with context stored as memories linked to specific entities, and a 3-channel search (embeddings + full-text + entity overlap, merged via Reciprocal Rank Fusion) across memories and entities alike. Incumbents' open source offerings provide keyword search at best. Both properties are already built into Motley and its open-source engine, SLayer. The upcoming 1.0 release will take expressiveness to a new level. Full post: motley.ai/blog-posts/post-ap… SLayer: github.com/MotleyAI/slayer

Nothing builds team spirit like reconciling revenue before the weekend

Cube vs SLayer-using agent? We ran a benchmark expecting a close fight. It wasn't close. A few weeks back we showed that an agent using our semantic layer (SLayer) beat a raw-SQL agent by 30%+ on a random selection of 265 live-sqlbench-large tasks. Fair follow-up question: how does that hold up against Cube, the incumbent open-core semantic layer? So we put open-source Cube behind an agent. There's no MCP server for it, so we wrapped its REST API for introspection and queries, auto-generated models from the DB schemas, adding dimensions and measures off the JSON columns' leaves, and handed the agent the same knowledge-base tools the raw-SQL agent had. Then we picked 10 tasks the SLayer-using agent had already solved — to give Cube an easy start. The raw-SQL agent had cleared 5 of them. The Cube agent solved zero. The first guess was a bug in the harness. There wasn't one. The logs showed two hard blockers: 1. Cube's schema metadata is so verbose it often blew straight past Claude Code's 25K tool-output limit. The agent couldn't see the whole schema, so it sat there hallucinating queries. 2. Nine of the ten tasks needed custom measures or dimensions built at solve time — ratios, derived formulas, CASE groupings that were provided in the knowledge base. Open-source Cube gives you no reasonable way to edit models on the fly. It would be possible to build around it: an external model store, a validate-on-edit compile loop, smart schema retrieval to dodge the token limit. That's a serious chunk of engineering to turn Cube into something it isn't — and it'd still take seconds to recompile on every single edit. Those are some of the reasons why we left Cube and built SLayer in the first place. So if you're planning to run Cube behind an agent, go in with your eyes open: you're writing the scaffolding yourself. Batteries not included. (Or use an agent-native semantic layer and skip the hassle. But we would say that.) Full post: motley.ai/blog-posts/we-trie… Original SLayer vs raw SQL post: motley.ai/blog-posts/when-th…

There's a take we keep seeing: just point the agent at your schema; it has everything it needs. We disagree, for a few concrete reasons. A schema tells you tables and columns exist. It doesn't tell you: → Which join is actually correct. customer_id joins to account_id in another table, not to the profile_id sitting right next to it in the same one, and the two ID formats look similar enough that you can't guess from the values. → The cardinality of that join. Many-to-one, one-to-one, many-to-many; get it wrong and you silently double-count or drop rows. No schema encodes this. → Which join path to take when more than one exists. This is a practical case: in our BIRD-Interact runs, the agent kept failing on certain tasks until we added deterministic join-path resolution to its tools. → How to find the right 20 columns out of a schema with hundreds, without dumping the whole thing (plus descriptions) into context every single session. → The tribal knowledge that doesn't live on any one column: why three near-identical tables all still exist, which one you're actually allowed to query. None of that is in the schema. It's exactly what a semantic layer is for: a governed place to put the joins, the cardinalities, the disambiguation, and the context, so an agent gets it right deterministically instead of guessing well. Join us on the 🤘 side. Full post: motley.ai/blog-posts/why-a-s… SLayer repo: github.com/MotleyAI/slayer

Been noticing a pattern with teams running agents against their warehouse lately. The query comes back fine, the number looks reasonable, nobody double-checks it, and it's already in the deck. Quick gut check, save yourself the trouble and go through this now: Does your agent mix up gross and net revenue without saying anything about it? Does every new question mean writing a fresh query, nothing reused from the last one? Can you actually trace how it landed on an answer, or does it just... arrive? Do finance, sales, and product all have their own version of the same metric? Has your agent stack outgrown whatever governance you set up for it six months ago? Zero or one, you're in better shape than most teams we talk to. Three or more, that's worth fixing before it ends up in a board deck, more on how at motley.ai.

62% of enterprises use AI agents in customer service. Only 34% use them for data & analytics. This gap will close fast. Data analytics is almost the perfect problem for an AI agent: the questions are open-ended, the data already exists, and the potential ROI is significant. The same dataset puts median payback for analytics agents at just 5.8 months. But analytics also exposes a harder infrastructure problem. Traditional software usually knows what data it needs in advance. An analytics agent doesn't. It needs to explore. To decide what to query. To join information across tables. To follow one answer into the next question. To formulate queries nobody explicitly designed when the system was built. That's what makes these agents powerful. It's also what makes giving them access to enterprise data difficult. Make the interface too narrow, and the agent is safe but not useful. Give it unrestricted database access, and it's expressive but impossible to control. I think the next step for agentic analytics is closing that gap: giving agents the freedom to reason over data, within boundaries the enterprise defines. That's the problem we're building SLayer around — not just governed access to data, but expressive access to governed data. As models get better at reasoning over structured data, this infrastructure layer is going to matter a lot more. Curious how this could work for your team? Try SLayer here → motley.ai/slayer