Agentic Analytics in Practice: A Slackbot, a Semantic Layer and Buy vs Build

Agentic analytics is everywhere in vendor pitches: talk to your data, AI-powered BI, semantic layers, self-service analytics version two. Nearly every analytics product is racing to put AI into every corner. Opinions about where this is heading are cheap, but accounts of building it inside a real company are rare, and so are honest answers to a harder question: did it survive real users and real expectations?

What follows is one such account, pieced together from a data scientist's work at a mid-sized subscription company starting in late 2025. It covers a first talk-to-your-data Slackbot built from scratch, the rollout to actual users, the strain of scaling a semantic layer and its infrastructure, and a build-versus-buy decision once the team went shopping for an enterprise BI tool. Since then the same person has moved into consulting, and almost every company met there is trying to work this out, which points to a real opening for data scientists.

The decision that mattered before any AI

Something happened in early 2025 that looked unrelated to AI at the time. The head of data saw the need to build the company's first information model, and an experienced data engineering consultant was brought in to lead it, with two data scientists involved at every step.

An information model is the layer that defines how data is structured, how tables relate and, above all, what metrics mean. Think of it as the shared language everyone at the company is meant to use when discussing data.

The technical side is fairly simple. The hard part is getting everyone to agree on the language. Ask what counts as an active user and each team answers differently. Marketing has a definition, product has another, finance has a third, and each is convinced its own is correct. Reaching alignment was slow and tedious, yet that work became the backbone of everything built afterward. Without the information model, putting a semantic model on top of the data would almost certainly have done more harm than good.

Building insights on demand

While the information model came together, the same data scientist was going through a personal shift. Time spent studying the job market showed more and more companies asking for AI skills, which led to teaching oneself to automate pieces of daily work: a data cleaning agent, an exploratory analysis workflow, and connections between AI, the data and its context.

What began as a productivity exercise grew into something larger, a piece of the broader move to agentic analytics (a label not yet in use then), in which traditional analytics was no longer enough. One of the biggest projects to come out of it was the Slackbot.

The idea was a data product that sits between dashboards and data scientists, for questions that should be easy to answer but do not justify building a new dashboard or reworking an existing one. Not every question deserves a Jira ticket.

Nobody had requested it. There was no waiting for permission or a green light. Most of it was built alone, as a prototype with a system design diagram and a short demo for the team. The decisive move was presenting it as something already built, not as a request for approval to begin. That left the team with almost no risk and gave the builder a chance to show work with real potential value, which was enough to win the support needed.

Rolling out and learning how people ask

The first users were a single team, marketing. That was deliberate: a controlled rollout, instead of a company-wide launch where things could break in ways that could not be managed.

The expected payoff was only a safer launch. In fact it revealed a great deal about how non-analysts ask questions. Marketers frame a question in terms of the business problem and not in terms of tables or metric definitions, so the system had to translate between the two. Analysts tend to be blinded by their own habits here.

It was clear from the start that this was a data product and not just a tool, so documentation, internal marketing and onboarding all needed attention, because those decide whether people actually use what gets built. The first few months consisted mostly of testing, and plenty of it.

What came next

The result was an MVP, so a decision followed on whether the product deserved further investment and what the next version would require. Building the system around the data was not the hardest part. When the question became what would make it more useful, the conversation turned to the scope of data the bot could reach, which meant growing the semantic layer.

The team then asked itself a set of questions. The first semantic layer lived as YAML files behind a Slackbot, so how would it grow? How could several people work on it? Did everyone even agree on the definitions?

Those questions arrived at a convenient moment, because a new BI tool was already under consideration, since the existing one no longer felt modern enough. The discussion moved from improving the Slackbot to whether a proper semantic layer was needed, and whether it should come bundled with the BI tool or stand alone.

Many enterprise BI products, such as Looker or Omni, embed a semantic layer. For this team one requirement held: if the BI tool came with a semantic layer, that layer could not be locked in, and it had to be portable into other tools. That is why the Open Semantic Interchange announcement of September 2025, promising a universal standard for semantic layers, mattered so much.

Build or buy, and why it matters less than it seems

The company ended up buying. The choice was Omni, which felt like a mix of Tableau, Looker and some spreadsheet capabilities. Several tools were vetted in November and December 2025, and Omni went live in early 2026.

It may sound anticlimactic: a story about a Slackbot built from scratch that ends with something bought off the shelf. The important point, which many data scientists miss, is that the skills still apply when a company buys. Building the bot taught lessons that went straight into integrating Omni: prompt engineering practices, evaluations, MCP and a deep understanding of what the semantic layer does.

Context engineering is a good example. It means controlling which information the model sees while processing a query: which tables, which metric definitions, which business rules. Having built the whole thing from scratch, the builder knew what to place in front of the model and, more importantly, what to leave out. That knowledge comes from building, not from reading documentation.

These skills also come up in interviews. Since moving into consulting, many companies appear that prefer to build in-house, mostly because they want a bespoke solution. Asking whether the skill is worth learning is therefore the wrong question. Learn it whatever the company decides, because it prepares for any challenge on any data stack.

Where the purchased tool fell short

Omni is a strong product from a young company that improves quickly, and it delivered plenty of value. The shortcoming met most often involved MCP.

A large part of the company still works in Google Sheets and Excel, and that will not change soon. The aim was to connect that data too, drawing on the same semantic model as everything else, so that a number in someone's spreadsheet meant exactly what it meant elsewhere. Doing that through MCP would have been ideal, but it was not possible.

The team wanted more say in the stretch between the semantic model and whatever consumes it: what is returned, and which tools are allowed to connect to it. A standalone semantic layer with the rest built in-house would give full control of the API. That is the tradeoff, and for many companies it will decide the matter. Where flexibility and complete control matter, buying may not be enough. Where speed and a solid out-of-the-box experience matter, a product like Omni goes very far.

Adoption decides everything

This topic deserves an article of its own. The most sophisticated system in the world is worth nothing if people do not add it to their workflow and trust it, and this is where many data scientists fall short. For a small team, finding the time was a real uphill battle, but adoption was taken seriously. The investments were:

• a video series for quick onboarding,
• several company-wide presentations,
• dedicated live workshops for key teams such as finance.

Anyone rolling out an AI tool internally should treat adoption as a product launch. That means internal marketing, training, and champions on every team who believe in it. Otherwise months of hard work end up as one more tool nobody uses. The work is tedious and none of it appears in a dashboard, yet it is the reason the whole effort mattered for a career.

Career effect

The Slackbot, the rollout and the lead role in the move to agentic analytics produced something concrete: bargaining power. That experience supported a request for promotion, and the promotion came.

The argument was not mainly about the Slackbot. It was about resourcefulness and staying at the leading edge of the field, then using that to build something that made the company better, in this case insights on demand. The strongest part was one that needed no stating: nobody asked for any of it, and nobody had to guide the work. A manager reads that as seniority.

Someone who can build such systems, understands the data and also understands the business is a rare combination, and companies know it. It also explains the later move into consulting, since demand is growing fast for data scientists who think about AI at a systems level and not just through ad-hoc chat prompting.

The takeaway

Agentic analytics is already happening and is not a future event. Companies are experimenting, rolling it out and finding out what works. Data scientists should take part. Whether the company builds or buys, the skills transfer everywhere: they raise value in the current role, strengthen a case for promotion and stand out in interviews.

It all began with a prototype made on the side, a system design diagram and a quick demo for the team. Waiting for someone to ask for this work is a mistake. Taking charge of one's own growth is the better route.