There’s a lot of talk about agentic analytics right now.
“Talk to your data” solutions, AI-powered BI, semantic layers, self-service analytics 2.0, etc.
It seems like every analytics enterprise tool out there is pushing hard to integrate AI into every corner of their solution.
And well, it’s no surprise that everyone on social media has an opinion on where this is heading. But very few are showing what it looks like to build this inside a real company, let alone answer the question: did it actually survive real users and expectations?
I’ve been on this journey since late 2025.
I built my company's first "talk to your data" Slackbot from scratch, rolled it out to real users, saw the challenges of scaling the semantic layer and the infrastructure behind it, and eventually navigated the build vs. buy decision when we started looking at enterprise BI tools.
It’s been a journey full of ups and downs, and I think I’m finally ready to share it all.
Because since then, I’ve moved into consulting, and I can tell you: almost every company I talk to is trying to figure this out, which means there is a huge opportunity for data scientists to capitalize on.
In this article, I'll walk you through the full story of how agentic analytics played out at my company, what I learned along the way, what I’d do differently, and what I think you should pay attention to if you want to be part of this shift.
The best decision we made (without knowing it)
In early 2025, something happened at Nextory that turned out to be crucial, but at the time it had nothing to do with AI.
Our head of data saw the need to rebuild (or rather, build our first) information model. We brought in an experienced data engineer consultant to lead the project, with data scientists (my colleague and I) involved every step of the way.
Alright, so what exactly is an information model, you might be wondering. In simple terms, it’s the layer that defines how your data is structured, how different tables relate to each other, and most importantly, what your metrics actually mean. Think of it as the shared language that everyone at the company is supposed to use when they talk about the data.
Believe it or not, the technical part of it is relatively simple. The real challenge is getting everyone to agree on that language.
Try asking, what is an “active user”? And you’ll get many different definitions across teams. Marketing has one. Product has another. Finance has their own version. And all of them think theirs is the right one.
Getting alignment on this was hard, and tedious. but we would soon realize that this work would become the backbone of everything we were about to build.
I have no doubt that without this information model in place, slapping a semantic model on top of our data would’ve done more harm than good.
Building insights on demand (from scratch)
Around the same time the information model was coming together, I had been going through my own transformation. I’d been analyzing the job market, seeing more and more companies asking for AI skills, and I started teaching myself to use AI to automate parts of my own work: building a data cleaning agent, an EDA workflow, and connecting AI to my data and context.
What started as a productivity thing turned into something bigger. I started seeing this as part of a broader shift into agentic analytics (although I didn’t call it that back then), where traditional analytics simply wasn’t enough anymore.
One of the biggest projects that came out of this was the “talk-to-your-data” Slackbot.
I saw this as a data product that would sit between dashboards and data scientists, for those questions that should be easy to answer but that shouldn’t require building a new dashboard or reengineering an existing one.
And also because not every question deserves a Jira ticket.
No one asked me to build this. I didn’t wait for permission or a green light to start. I built most of it on my own, came up with a prototype, put together the system design diagram you see above, and presented it to my team with a quick demo.
The key was that I presented it as something that was already built, not something I was asking permission to start. That made a big difference!
There was very little risk for them, and it gave me the opportunity to demonstrate what I had been working on and bring something with real potential value to the team.
That was enough to get the buy-in I needed.
Now the question was: who do I roll this out to first?
Rolling it out (and what I learned about users)
I rolled it out to only a specific team: the marketing team. This was intentional. I wanted a controlled rollout, not a company-wide launch where things could break in ways I couldn’t manage.
I thought that all I was getting out of this was just a safer launch, but I also learned so much about how non-analysts ask questions about data.
I had been so blinded by my own ways …
The way marketers ask questions is fundamentally different from how we analysts ask questions. They don’t think in table structures or metric definitions; they think in business context. And that was the gap I needed my system to bridge for them.
It was clear to me from day one that I was building a data product, not just a tool, so I had to think about documentation, internal marketing, and onboarding. All the things that make or break whether people actually use what you build.
This is basically what the first few months in the life of my new product looked like: lots and lots of testing.
So…what’s next?
Keep in mind that I built an MVP, and so eventually I needed to decide if continuing to build this product was worth it, and what that next version would require.
Building the system around the data wasn’t the most challenging part, when it came time to ask what would make our product more useful, the conversation revolved around the scope of the data it had access to, which meant growing the semantic layer.
We started asking ourselves: okay, we have our first semantic layer, but it lives as YAML files behind this Slackbot. How are we going to make it grow? How can we all work on it? Do we all even agree on the definitions?
These questions were natural. And they came at the right time, because we were also in the market for a new BI tool, because the one we had felt like it wasn’t modern enough for our needs.
So the conversation shifted from “how do we improve the Slackbot” to “do we need a proper semantic layer, and should it come bundled with our BI tool or live independently?”
Many enterprise BI tools (like Looker or Omni) come with a semantic layer embedded. But to us, one thing was important: if we were going to buy a BI tool that came with a semantic layer, the semantic layer couldn’t be locked in. We needed the ability to bring it into other tools.
💡 This is why the OSI announcement from September 2025 was such a big deal to us. It promised a universal standard for semantic layers. I wrote about it in detail if you’re curious.
All of this brought us to the classic question.
Build vs. buy (and why it matters less than you think)
Should we build in-house or buy?
At Nextory, we ended up buying. We went with Omni, which to me felt like a combination of Tableau, Looker, and some spreadsheet capabilities. We vetted several tools around November and December 2025, and rolled out Omni early 2026.
Now, I know how this sounds. You read this far into a story about someone building a Slackbot from scratch, and the ending is that we bought something off the shelf.
But here’s what I want to emphasize, because I think a lot of data scientists get this wrong:
Even if your company ends up buying, the skills still apply.
Building the Slackbot myself taught me so many valuable things that I then directly applied as we were integrating Omni. Things like prompt engineering best practices, evals, MCP, and understanding the role of the semantic layer at a deep level.
Take context engineering, which is essentially about controlling what information the AI model sees when it processes a query: which tables, which metric definitions, which business rules. Because I had already gone through the process of building all of this from scratch, I knew what to put in front of the model and, more importantly, what to keep out. That knowledge didn’t come from reading documentation; it came from building.
And you will need to talk about these skills in interviews. Since I started working as a consultant, I’ve come across many companies that go the build-in-house route, mainly because they prefer a bespoke solution.
So to me, the question of “should I even learn this skill?” is not even valid. Learn it regardless of what your company decides, because that is the best way to prepare for any of the challenges you might encounter (regardless of what data stack you are on).
📣 Join my upcoming free live workshops
Every registrant gets the recording and the demo files.
Omni: what worked and where it fell short
Omni is a great tool. It’s still a relatively young company, which means they’re improving fast, and for what it offers, it gave us a lot of value.
But it had shortcomings, and the one we kept running into was MCP.
Take Google Sheets and Excel. A lot of the company still works there, and that’s not going away anytime soon. What we wanted was for that data to be connected too, and pulling from the same semantic model as everything else, so that a number sitting in someone’s spreadsheet meant exactly what it meant everywhere else. Doing that through MCP would’ve been great, but we couldn’t.
We wanted more freedom over what happens between the semantic model and the tools consuming it, what we get back from it, and which tools we’re allowed to point it at.
This could potentially be solved by going with a standalone semantic layer and building the rest in-house, which gives you full control over the API.
So that’s the tradeoff, and for a lot of companies it will be the deciding factor. If you need flexibility and full control, buying might not be enough. If you need speed and a solid out-of-the-box experience, a tool like Omni gets you very far.
Either way, the harder part was still ahead of us.
Adoption is everything
Honestly, this topic should probably be its own article.
You can build the most sophisticated system in the world, but without people adding it to their workflow and trusting it, you have nothing. And I know this is where a lot of data scientists fall short.
We took adoption seriously, although it was truly an uphill battle to make the time for it, especially since we were a small team.
These are some of the things we invested in:
Filmed a video series to help with quick onboarding.
We made several company-wide presentations.
We even did dedicated live workshops for key teams, like finance.
So if you’re rolling out anything AI-related internally, treat adoption like a product launch.
You need internal marketing,
You need training
You need champions on every team who believe in it.
Otherwise, your months of hard work, sweat, and tears will simply result in just another tool no one uses.
That work is tedious, and none of it shows up in a dashboard. But it’s the reason any of this ended up mattering for my career.
The career impact
All of this, the Slackbot, the rollout, leading the shift towards agentic analytics at my company, gave me something concrete: leverage.
I used this experience to ask for a promotion, and I got it.
And the case I made wasn’t really about the Slackbot. What I talked about was being resourceful and staying on the edge of my field, and then using that to build something that could genuinely make the company better, which in this case was insights on demand. But the strongest part of the argument was the part I didn’t have to make: nobody asked me to do any of this, and nobody had to hold my hand while I did it. That’s what my manager read as seniority.
Here’s the thing. Being the person in the room who can build these systems, who understands the data, and who also understands the business is a rare combination, and companies know it.
This is also a big part of why I eventually decided to move into consulting. The demand for data scientists who can think about AI at a systems level, not just use ChatGPT for ad-hoc prompting, is growing fast.
What I want you to take away from this
Agentic analytics is a shift that is already happening. It’s not a future thing. Companies are experimenting with it, rolling it out, and figuring out what works.
If you’re a data scientist, you should be part of this. The skills you build here, whether you end up building in-house or buying, transfer everywhere. They make you more valuable in your current role, they give you leverage for promotions, and they set you apart in interviews.
And remember how this started for me. A prototype I built on the side, a system design diagram, and a quick demo for my team.
Don’t wait for someone to ask you to build this, take control over your own career growth.
A couple of other great resources:
🤖 Want to go from Chat Window to AI Analyst? Check out my free live workshop series for Data Scientists.
🎥 Want to follow along on YouTube? I just launched a channel for data scientists. Don’t forget to subscribe to not miss any videos.
Thank you for reading! I hope this guide helps you decide how to stay relevant.
- Andres Vourakis
Before you go, please hit the like ❤️ button at the bottom of this email to help support me. It truly makes a difference!