Systems | Development | Analytics | API | Testing

You can get an AI Analyst from most of the players, or you can try to build one yourself. Fewer let you decide what it knows, what it can touch, and who can use it. And even fewer still let you define what it won't do. You need all three before you hand one to a team or put one inside your product. In most of the product experiences, your AI analyst's context had two homes: one expert's head, or org-wide instructions.

Imagine hiring the sharpest analyst you have ever met. They know the industry cold. They reason like nobody else on the team. They write like a Nobel laureate. Then you realize you never gave them a badge, a laptop, or a login to the CRM. And a week later, nothing has shipped. Every task still routes back through you, because the analyst can think but can’t touch anything. You’ve just hired a very expensive conversation partner. That is most people's experience with AI agents today.

Every analyst has a version of this “Monday blues.” A leader pings asking for the quarterly forecast, wants it broken out by region, and needs it for a call in thirty minutes. The fastest way to do this? Pull the data out of your tool, paste it into Excel, and build the report there. Thirty minutes later, you've got the report: three new formula columns, a pivot view summarizing the regional split, and conditional formatting flagging the outliers.

Most AI agents can write SQL. The problem is they write it against the wrong definition of revenue, for the wrong team, using the wrong business rules, and you won't catch that in a demo. Before you evaluate a single semantic layer vendor, there are four things worth getting right first. The semantic layer market has never been more crowded. Every major analytics vendor, data platform, and BI tool now claims to have one.

You’ve rolled out a modern data stack, built self-service dashboards, and empowered your team to ask their own questions. Job done, right? Not quite. The data landscape is shifting rapidly beneath our feet, which makes it critical to understand how to build your AI for BI platform so you can scale and navigate technology evolutions.

Spotter Memory is now generally available.

Agentic analytics, embedded customer-facing reporting, and everyday business metrics now demand the same thing: performance at massive scale, and answers fast enough that a business user never notices the wait. Most generic databases were never designed for that combination. They assume a small population of analysts writing SQL and query latency measured in seconds, not AI agents and business users asking questions around the clock.

Analytics vendors claim their AI answers questions accurately, but almost none of them will show you how they checked. The standard move is a percentage with no denominator: "90%+ accuracy on internal benchmarks." No dataset you can download. No scoring method you can inspect. No competitor runs under the same conditions. You're asked to trust the grade without ever seeing the exam1 We ran the exam in public terms instead.

Every organization says it wants self-service analytics, but very few have it. What actually stalls true self-service analytics is the invisible work that has to happen before anyone can ask a data question: the semantic layer, query engine, security model, and analytics app. That work lands on your product and data teams, who are already time-strapped to deliver core features and strategy, and it lands on them again every time a new question, a new tenant, or a new dashboard request arrives.

Imagine handing a new developer an SDK, a stack of docs, and a deadline. They read for twenty minutes, write ten lines, break something, go back to the docs, second-guess a prop name, and try again. Now multiply that by every component they'll embed, every agent, every color scheme, and every project they'll touch. That gap, between "I know what I want this to look like" and "I know the exact syntax to make it happen," is the tax every developer pays on embedded analytics.