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.¹

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: amount

2. Compile / 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 10

which returns either a SQL query or results. And that’s it. No server², 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 .*rc files — 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.yml files on disk, which means they’re greppable, embeddable, indexable, annotatable. Post-aggregation calculations can be hardened as .motif.yml files. 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.

1. It’s finally time for headless BI to exist, George Xing. :)

2. 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.