Your semantic layer should be a library call, not a toll booth.
Introducing Airlayer: the in-process semantic engine, alongside some commentary on the future of data
Youāve been tasked to build an agentic analytics system for your organization. Unlike the poor souls over at OpenAI, you understand that unconstrained text-to-SQL is dangerous, so you look to building a runtime with semantic layers and MCP. Your company is on Looker, so you start researching alternatives (b/c itās always a good time to get your company off Looker). You consider Cube, but donāt quite understand how it makes anything better. You consider Omni, but donāt quite understand how it makes anything better. You consider dbt, but you donāt quite understand how it makes anything better. You connect, begrudgingly to Looker. And your proof-of-concept works, yay!
But it doesnāt work that well. Itās slow ā the Looker latency tax from the roundtrip server calls is a few seconds every time. Itās somehow inaccurate ā your LLM is struggling to differentiate between ambiguous Looker definitions, and what was once your Looker swamp is now your context swamp. Of course, something is better than nothing, but the system feels slow, bloated, middling. Not to mention you have to deal with OAuth/service account limits, and the Looker sales reps are now trying to upsell you into an āembedded pricing modelā for a cool $500k/year.
This is the state of things in 2026. And itās not just Looker. Every semantic layer on the market is slow, tethered to a monolithic cloud server. Every semantic layer is inaccurate, missing truly LLM-native grammar. And every semantic layer is expensive ($30-50k to start??). You deploy it, you call it over the network, you pray to Claude that the answers are correct, and you pay for the privilege. Some of this made sense when the primary consumer was a human clicking through a BI tool, but when primary consumption happens through an LLM, the architecture is painfully ill-conceived. An LLM doesnāt click buttons [well], it reads text. To boot, because these products were all built before AI, their primitives are only coincidentally satisfactory. And the thought leadership is confusing: semantic layers are somehow both āfoundational infrastructureā for AI systems and brittle legacy architecture, and you catch yourself wondering if it wouldāve been easier to just build a text-to-SQL system yourself.
And yet the semantic layer itself isnāt really the problem. We spent the last year trying to throw out the baby, but itās a fine place to start: measures and dimensions capture most of the variance reduction you need for deterministic querying in a way that spans the space quite efficiently ā the error surface shrinks dramatically with very little effort. It just happens that every implementation is trapped by its own business model. It needs to be faster, not attached to a server. It needs to become a completely open protocol, not a grammar constrained by the need to be monetized as a BI tool. It needs LLM-native extensions that, sure, donāt fit neatly into the BI paradigm, but are crucial for LLM usability.
So we built it ā enter airlayer.1
Introducing airlayer - fast, AI-native, open
Airlayer is a library and CLI. No server, no MCP, no $50k license, and LLM-native. Apache-licensed, written in Rust, designed to be embedded/scripted/tool-called in whatever system needs it. Hereās the high-level idea:
1. Define measures/dimension in yaml.
name: orders
table: public.orders
dialect: postgres
dimensions:
- name: status
type: string
expr: status
measures:
- name: total_revenue
type: sum
expr: amountCompile / query it with
airlayer query
Below is a CLI command example, but itās also light enough to live as a function call in your application.
# add --execute -c config.yml to run against a database
airlayer query \
--dimensions orders.status \
--measures orders.total_revenue \
--filter orders.status:equals:active \
--limit 10which returns either a SQL query or results. And thatās it. No server2, just a place to define and compile your semantic models. This might seem a bit spartan, but hereās what you get from the LLM perspective:
It's fast. Airlayer is an in-process library call, not an HTTP request. Each call takes microseconds (~10e-6 s) as opposed to potentially seconds for network calls. The speed-up matters because agents donāt usually call one query, but operate in a loop: inspect, query, read, decide, query again. This sort of multi-step investigation through a hosted semantic layer can add up to a ton of dead wait. Through airlayer, the agent can spend its time reasoning, not waiting on the network.
Itās less unwieldy: no servers, no fuss. No reliance on servers means airlayer is easier to both set up locally and scale out. Local use doesnāt require muddling through MCP servers, auth tokens, and
.*rcfiles ā you just need access to the semantic definitions, a CLI tool, and some skill files. Deployed use doesnāt require scale-out servers or custom permission pathways to handle multi-tenancy ā you just gate at the software level and import the semantic definitions. Itās light so you can scale around it.Itās more accurate. Queries can be saved as retrieval surfaces, not just execution templates. In every other semantic layer, a saved query is something a human bookmarks as a result set or dashboard. In airlayer, a semantic query is something an LLM can find. Specific queries / groups of semantic queries can be saved as
.query.ymlfiles on disk, which means theyāre greppable, embeddable, indexable, annotatable. Post-aggregation calculations can be hardened as.motif.ymlfiles. The query artifacts arenāt just executable, theyāre discoverable. Thatās the difference between a semantic layer designed for humans to click through and one designed for agents to search. More to come on this later.Itās free and open. There is no monetization pathway here, by design. Weāre not a semantic layer company ā weāre a company that needed this utility and believes it should be infrastructure, not a product. Thereās no premium tier. If the semantic layer is going to become the contract layer for AI-native data systems, it canāt be a toll booth.
Final comments
A few years ago, there was a lot of talk about āheadless BIā ā the idea that you could separate the semantic/modeling layer from the visualization layer and let different consumers plug into the same definitions. It was a good idea that never quite materialized, because every company that attempted it couldnāt resist the gravity of building a full BI tool on top.
Iāve deliberately avoided building a GUI for airlayer, and the reason why is quite simple: this is not a BI tool. Itās a semantic engine. The moment you add a drag-and-drop interface, you risk recapitulating the same problem: a human-first surface that an LLM has to work around, a standard beholden to human interaction. The whole point is that the interface is YAML and CLI/library. Itās headless BI, finally, for real this time. Not [just] because weāre appealing to idealistic principles, but because the thing consuming it has no eyes.
Itās finally time for headless BI to exist, George Xing. :)
And if you really want a GUI, you can build one on top ā I vibe-coded one in about 20 minutes. Maybe Iāll release one at some point, but I canāt help but feel that it somehow feels like a philosophical betrayal. THIS IS NOT A BI TOOL.



Goodbye $50K semantic layers!
š this is revolutionary!