Looker Taught a Generation to Think in Models. The Lesson Outlasted the Company.

Looker sold to Google for $2.6 billion in 2019. Last month, the man who built it sat on a call with three of his former employees, showing them how to give away its successor for free.

That contradiction is the whole story.

Looker was the connective tissue

I was one of the founding members of Looker's Chicago office. Jeff Garcia was one of Looker's top sales reps. Andrew Searson ran internal analytics there. Most of the people who work with Motif today spent time on the Looker side of a screen at some point, either as employees, as customers, or building on top of what it made possible.

Looker taught a generation of data people to think in models before they thought in dashboards. Most of those people have moved to other tools since then. The way of thinking went with them.

The reunion nobody scheduled

Last month I sat in on a call with Lloyd Tabb, Looker's founder, Jeff, Andrew, and two builders, Bruna and Jorge, who are exploring what it looks like to build workflows and content experiences on top of Lloyd's current project. Lloyd left Looker after the acquisition and spent the years since building Malloy, an open source language for defining a semantic model. His current focus is Malloyyo, a microservice that sits between an AI and an analytical database and exposes the data as a Malloy semantic model.

The call was a working session between people working out where the lines should sit between an open semantic layer, a dashboard product built on top of it, and the agent connecting the two. Where those lines belong ended up driving most of the conversation.

What self-service actually looks like now

Bruna walked through a live build. She had a Fathom transcript from an earlier call where a client discussed a real problem: too much unsold inventory, and a decision to make about what to buy for next season. She fed that transcript to an agent she has been building workflows around, and asked it to pull the core question and required data points out of the conversation, propose a dashboard structure, connect it to the client's Malloy model, and style the result using the client's brand guide.

The result was a styled, working dashboard built from a meeting transcript and a semantic model, with no one touching a chart library or a design tool. Bruna's honest assessment, after years of manually rebuilding client dashboards in Looker and other tools: she could never have produced it herself, not at that speed, not without a designer.

That is not a demo of AI making dashboards prettier. It is a demo of what happens when the thing doing the interpreting, the agent, and the thing holding the business logic, the semantic model, are cleanly separated. The agent did not have to guess what "unsold inventory" meant. It looked it up.

The unglamorous work that makes an agent trustworthy

Lloyd spent a chunk of the call on something less flashy: which model should sit at that interpretation layer. He has been testing Claude's Haiku against Gemini for the job of routing a question to the right place in a Malloy model.

His conclusion was not "use the smarter model." It was that the model matters less than the guardrails around it. A well-built semantic layer acts like a compiler, catching a cheap, fast model before it goes off course and redirecting it to the right documentation, the right join, the right definition. Get that layer right, and even an inexpensive model becomes reliable enough to trust with the interpretation step. Get it wrong, and no model, however capable, will save you from a mismatched answer that looks confident.

Self-service failed because of the interface, not the analysts

Self-service never quite worked as intended. Most people never learned the Explore interface well enough to ask their own questions without help. The tool built to remove the analyst from the loop mostly just gave analysts a faster way to answer questions themselves.

What Lloyd demoed next was his attempt to fix that, twelve years later. Every query in his current interface generates a link. You can favorite it, return to it, ask a follow-up, and the assistant remembers what you already asked. It is a full history of the questions your business has answered, sitting alongside the questions everyone else has favorited. It looks less like a dashboard and more like a shared thread of institutional memory.

The mechanism is chat instead of a query builder. But the reason it might finally deliver on self-service has nothing to do with chat feeling more natural. It is that nobody ever needed a friendlier interface. They needed to not have to write the query at all, while still trusting that the answer was grounded in a real definition instead of a guess.

What the dashboard actually is

For the first eighteen months of Looker's life, there was no dashboard. Lloyd built the model and a screen where you typed a question and got an answer. Users asked for dashboards anyway. He shipped them. Dashboards became the thing most people think Looker was for.

Jeff put it plainly on last month's call: a dashboard is a scoreboard for people who are not in the data every day. An analyst never uses one to make a decision. They use it to show their boss the decision has already been made. That distinction matters more now than it did in 2012, because if the agent can answer the question directly, the dashboard becomes something different. A receipt, not a destination. A snapshot you generate on request because someone needs to see it, not because it holds the answer.

What has changed is that an agent can now produce that receipt tailored for whoever is receiving it, whether that is the CFO, the buyer, or the store manager. As long as the logic is enforced at that layer, not just defined.

The answer lives in the data model.

“The data model is the asset. The report is a receipt.”

The pattern we keep seeing in client work

One person on the call runs data for a large financial services company. He has strong opinions about what a good visualization looks like and exactly how agents should fit into his analytical workflow. His current setup gets him partway there. It does not move fast enough for what he is trying to build, and the output rarely looks the way he wants it to. We have watched versions of that same frustration with clients in retail and in healthcare. The semantic layer is what none of them can move independently of the tool.

Most BI platforms have bolted AI features onto the product in the last two years. The pitch is convenience. The tradeoff is control. The semantic layer, the definitions of revenue, margin, and customer your business runs on, lives inside a vendor's product, shaped by their data model and their defaults. The AI sitting on top of it runs on their model, their guardrails, their version of what a trustworthy answer looks like. Lloyd made the point plainly on the call: the guardrails around a model matter more than the model itself. If you do not own the guardrails, you are trusting someone else's.

That is the real cost. Your business logic is yours. The question is where it lives, how portable it is, and whether your agents can reach it without going through a vendor first. Logic written inside a BI tool's semantic layer works inside that tool. It does not extend cleanly to the workflows and agent pipelines being built around it. For someone with strong opinions about how his data should look and how agents should fit into his analytical flow, that portability is the difference between a tool that gets him partway there and a foundation he can actually build on.

What this means for how we build

The interesting question is not whether an AI agent can do BI for you. Plenty of vendors will sell you that promise this year. The question that determines whether an organization can adapt is simpler: is your business logic portable enough that a person, a dashboard, an agent, or whatever comes after agents can use it without asking your vendor's permission first?

Motif starts every engagement with that question, not with the tool. Looker taught a generation of us to think in models first. The lesson outlasted the company. It should outlast whatever comes after it too.