# The analyst you can't afford, already hired *By Peter ยท 2026-06-28* > There are two ways to let an AI read your studio's data: query each live system one question at a time (the API approach, like drinking through a straw), or bring all your history into one connected place the AI can read at speed (a data lake). Lakes win on speed, on connecting systems that don't talk to each other, and on safety, but they take a team of data engineers to run, which is why they've always been enterprise-only. Kula Intelligence builds and runs the lake for you, so the AI you already use can answer questions about your studio as if it had read every number in the building. ## Key takeaways - The AI model is the least interesting part of Kula Intelligence. The engineering that matters sits underneath it, in the data layer. - The API approach connects an AI to your live systems one question at a time. It works for a single lookup but collapses on real questions that span months and multiple systems. - A data lake brings all your studio's history into one place built to be read fast, so complex questions come back in seconds instead of minutes. - The biggest advantage of the lake is linking: your booking system and your payment system don't know they're describing the same member until something connects them. The lake makes that link. - Enterprises run data lakes with teams of data engineers and analysts. That's why the model has been out of reach for small businesses, who need it just as much but can't staff it. - Kula Intelligence builds and runs the lake for the studio, so the work an enterprise pays a team to do happens underneath, handled, invisible to the operator. --- When people ask how Kula Intelligence works, they usually expect me to name a model. Which AI is it? The honest answer is that the model is the least interesting part, and it's not the part we built. The work we did sits underneath the AI, in the boring plumbing nobody wants to talk about and everybody quietly needs. So let me talk about it. Because the choice we made there is the whole reason Kula gives you a straight answer about your studio in seconds, instead of a slow, half-right one. ## Two ways to let an AI read your business There are really only two ways to connect an AI to your studio's data, and the difference between them decides everything about what you get back. The first way is the one most people reach for. Leave your data where it is, in Mindbody, in Stripe, in your inbox, and have the AI ask each system a question every time you do. You want to know who hasn't been in lately, so the AI calls your booking system, waits, gets a slice of rows back, and reads them to you. This is the API approach. Think of it as drinking through a straw. One question, one thin tube poked into a live system, a few sips pulled back out. For a single lookup, a straw is fine. "When did Sarah last book?" One sip, done. But your real questions aren't single lookups. "How's the reformer cohort tracking over the last six months, and which of them are slipping?" is not one question. It's hundreds. Every member, every visit, every plan, every payment, cross-referenced across six months and three different systems that don't know each other exist. Through a straw, that's hundreds of sips, each one waiting in line behind the last. By the time the answer arrives (if it arrives), you've made a cup of tea and forgotten what you asked. The second way is the one we chose. Bring the data together first, into one place built for the AI to read fast, and let it wade through the whole picture at once. Not a straw into a live system. A lake the AI can swim in. ## Why the lake wins When all of your studio's history lives in one place, already pulled together, already linked, already cleaned up, three things change. It's fast. The AI isn't waiting on five different systems to answer one at a time. The whole picture is right there, so "six months of the reformer cohort" comes back in the time a straw would still be on its third sip. It's connected. This is the part that matters most and gets talked about least. Your booking system knows about visits. Your payment system knows about money. Neither of them knows the visit and the payment are about the same person, that link doesn't exist until someone makes it. In the lake, we make it. Every visit is tied to the plan it was drawn against and the sale that paid for it, so a question like "are the members on class packs staying as well as the members on memberships?" actually has an answer. Through a straw, it never could, because the straw can only ever see one system at a time. It doesn't break anything. The lake is a read-only copy. The AI reads your history; it never touches the live systems your studio runs on. It can read everything and break nothing. This isn't a new idea, by the way. The biggest companies in the world (banks, airlines, retailers) have been building exactly this kind of data lake for years. There's a whole industry around it. Databricks, the best-known name in the space, is built on the lake model and worth tens of billions of dollars. ## So why doesn't every studio have one? Because building and running one is a real job. Several jobs, actually. The companies that run data lakes employ teams to do it. Data engineers to pull everything together. Analysts to make sense of it. People whose entire week is keeping the plumbing clean so the answers stay trustworthy. That's why the lake has always been enterprise-only, not because small businesses don't need it, but because small businesses can't staff it. A boutique studio can't hire a data engineer. You shouldn't have to know what one is. You're already on the laptop on a Sunday night with five tabs open and spreadsheets that don't talk to each other, the last thing you need is a sixth system and a hiring problem on top of it. That's the gap Kula closes. We built the lake, and we run it for you. The pulling-together, the linking, the cleaning, the keeping-it-honest: the work an enterprise pays a team to do, happening underneath, handled, so you never see it. What you see is the chat window you already use, answering questions about your own studio as if it had read every number in the building. > Enterprises build a lake because they can hire the team to run it. You can't, and you shouldn't have to. So we hired it for you. ## What the model actually does This is why I said the model is the least interesting part. The AI (Claude, ChatGPT, whichever you use) is good at language. It's good at understanding what you asked and saying the answer back plainly. What it is not good at is finding the answer in a mess of disconnected systems that were never built to talk to each other. No model can, because the connections aren't there to find. Our job was to do that finding ahead of time. By the time you ask your question, the heavy lifting is already done: the data is gathered, the links are made, the picture is whole. The AI just reads it back to you. We supply the grounded, connected numbers. The model supplies the plain English. Neither half works without the other, and the half that took years to get right is the one you'll never have to think about. That's the whole design, and it's a deliberate one. Studios are not short on dashboards. They're short on answers. We didn't think the fix was another tool to learn, we thought it was doing the unglamorous work underneath so the answer could just appear. So that's what we built. --- Source: https://kula.digital/blog/the-analyst-you-cant-afford-already-hired