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.

That is not nostalgia. It is a pattern worth naming. Looker taught a generation of data people to think in models before they thought in dashboards. Vendors have changed since then. The way of thinking did not.

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 putting an AI-first analytics tool 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 Malloy-O, an agent that sits between a chat interface and a Malloy model and answers questions in natural language.

The call was not a pitch. It was a working session between people trying to figure 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. That question turned out to be more interesting than any roadmap slide.

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 inside the tool she is building, Malloy Studio, 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 Omni: 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.

Is a dashboard even the right output

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, nothing more. Users asked for dashboards anyway, and eventually he shipped them, and dashboards went on to become the thing most people think Looker was for. On last month's call, the same argument was happening again, this time about whether AI needs a dashboard at all.

Jeff's position: a dashboard is a scoreboard for people who are not in the data every day. An analyst never uses a dashboard to make a decision. They use it to show their boss that the decision has already been made.

Lloyd pushed further. If the real question is "what should we buy next season," that is not a dashboard question. It is a conversation, and it ends in a plan, not a static chart. He pointed to Hex as the tool winning that use case, not because its visuals are better, but because it treats analysis as a narrative you build toward a decision, not a report you glance at.

Neither of them was arguing that dashboards should disappear. Jeff was clear that dashboards are table stakes, something you still have to ship. But a dashboard built this way is a receipt, not a destination. It is a snapshot of a conversation you already had, generated on request from a model that already knew the answer, easy to regenerate and easy to throw away. That only holds up if every tile in it maps back to a named view inside the model instead of a one-off query someone wrote by hand. Name the view once and reuse it everywhere, and the report stops being the thing you were protecting.

“The 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 still paying enterprise BI pricing for a semantic layer, while waiting on that same vendor to ship any tooling built for how agents work in practice. We have watched the same frustration play out with clients in retail and in healthcare. They are not underwater on the visualization layer. They are underwater on a semantic layer they do not control, built by a vendor whose incentive is to keep them inside a walled interface instead of handing back the business logic they already paid to define.

It gets worse when that same vendor bolts AI features onto the platform, which most of them have done in the last two years. Those features get metered separately from the license already being paid. The result is paying twice for the same question: once for the seat, again in tokens spent against whatever model the vendor put behind their assistant, priced and governed entirely on their terms. Put an agent directly on top of a semantic layer you actually own, and that spend lives in one place, with a model you chose.

That is the real cost of vendor lock-in. It was never about switching dashboards. It is about who controls the definitions of revenue, margin, and customer that the rest of the company runs on, and increasingly, who controls the bill for asking questions about them.

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.