Community Spotlight

Stan Dumont on how agentic AI can bridge the data-business gap

By Ioanna Lykiardopoulou

Every month, we spotlight one member for our community. At KickstartAI, we believe that meaningful progress starts with individuals – builders, researchers, founders, and practitioners – who are applying AI in bold, practical ways. Our Community Spotlight series celebrates their work, their challenges, and the lessons they’re learning along the way.

This month, we’re featuring Stan Dumont, Data Scientist at Lynxx. With a background in econometrics, Stan now focuses on deploying ML and GenAI agents particularly for the transport sector.

For Stan Dumont, data scientist at Lynxx, a big challenge for AI professionals is to bridge the data gap between data and business. That gap is exactly where he believes agentic AI can help: shifting us from an era of seeing data to an era of talking with it.

“As a community, we’re very good at creating clear overviews, polished dashboards, and compelling visualizations,” Stan says. But every new insight those tools surface, he adds, also generates new questions. Why did this number change? Why is revenue higher than last month? What caused this spike?

“These are exactly the questions a static graph, no matter how interactive, struggles to answer,” he explains. That’s what he defines as the data-business gap.

Stan saw this play out repeatedly in dashboard projects. “You’re always balancing,” he says. “From the data, you can derive all kinds of insights and KPIs. But if you include too much, users don’t know what they’re looking at or where to click. If you simplify too much, they come back asking why they can’t find this or that. Or they might have additional questions in any case.” 

Traditionally, bridging this data-business gap meant manual work: analysts digging through SQL queries, pulling ad-hoc reports, and answering questions on demand. 

That’s what pushed Stan to experiment with agentic AI. “I thought that if AI can write SQL, it can perhaps handle data analysis too.”

About two years ago, he and a colleague ran a two-day “pressure cooker” prototype – just a small local database and a language model generating queries. The system surfaced answers faster than writing SQL by hand, and also enabled users with no technical knowledge to access the data themselves. 

“That was an eye-opener for me,” he says, “and I see people increasingly interact with data through natural language only.” 

Using agentic AI in practice

One example Stan shares comes from a project with a large railway infrastructure organization in the Netherlands, working on the electricity network around train operations.

The project started with consolidating scattered data and building dashboards, before moving to predictive models that estimate risk ranges for extreme load situations.

The platform was strong, with clean data, solid models, and valuable predictions, Stan says, but something was missing: combining all the insights and providing them to the user in a way that they can understand and actively interact with. 

“Why do I get this electricity peak load? What was it for the last year on this point? What will change in the future? Why is the load lower now? These are all diverse questions that you can’t put in one overview by default, but with agentic AI it’s possible to answer them and get closer to the user,” Stan says.

Building and integrating agents into a data architecture 

When it comes to building AI agents, Stan and his team have experimented with different architectures, the main contenders being LangChain and PydanticAI, a Python package that includes agent functionality.

“In practice, LangChain felt a bit bloated for what we needed,” Stan explains. Many of its features also require sending data through a LangChain server. “We’re not working with conversational data – we’re working with raw tables – and we didn’t want to push that outside our environment.”

PydanticAI turned out to be a better fit. It’s more “bare-bones,” but structured and clean, and it gave them enough control to build a production-ready system without unnecessary complexity. For Stan, that made it a safer choice – both for data protection and for keeping the codebase simple and easy to maintain. 

As for integrating agentic AI into an existing data architecture, Stan’s starting point is simple: where is the data stored? “If all your data is stored in one database, you only need to create one tool to contact it and query it for you. And then you need to connect this tool to the agent,” he says. 

“But if the data is scattered, which is more often the case, you have to think: do I need to create a tool for every system or do I need to manually combine it first and then feed it to the agent?”

He describes two possible routes. The first is to create a tool to connect to every system, which might eventually confuse the agent. The second one is to bring similar data sources together in one place and let the agent query that single system.

In his projects, he usually chooses the second option. That choice doesn’t remove the hard work upfront: data cleaning and modeling. “Agentic AI isn’t a solution for data cleaning,” Stan says. “That part is still there, just like in every other AI project.”

Safeguards and trust 

Stan is very clear about one thing: you can’t guarantee that an AI agent will always understand the context perfectly. “That was a big mindset shift for me,” he says. “With a model or a dashboard, you can measure accuracy and double-check every number. With an agent, you can’t get to 100% correctness on every question – and if that’s the requirement, you shouldn’t use one.”

What matters is the trade-off. “In many cases, people either have no answer at all, or they spend hours digging through data and files,” he says, arguing that if an agent can give a good answer in a minute with a high chance of being right, that’s already a big step forward – as long as users can tell whether they should trust it. That’s why transparency is central: Stan’s team always shows the queries the agent runs and the raw data it returns, so users can see exactly what the answer is based on.

“The interpretation of the data that generates the final answer could contain errors, but the models are typically good enough now.”

Changing the system prompt can change the agent’s behaviour, so the team maintains example questions and expected answers and runs them as end-to-end tests. They use an “LLM as a judge” – a second model that checks whether the agent’s output still matches what it should do –  and are currently experimenting with token uncertainty (log probabilities) to estimate model confidence. If uncertainty is too high, the agent simply refuses to answer, returning: “Sorry, I can’t answer this question.”

Biggest learnings 

For Stan, the biggest learning was a mindset shift in how he thinks about value. “With a predictive model, you can measure accuracy and often translate that into clear business impact,” he says. “With an agent, it’s different. You have much less control over the value, and you can’t easily verify it yourself – the value really depends on how people use it.”

His advice to other data scientists and engineers is to just start. “When I studied five years ago, I’d never heard of agents,” he says. “I just started experimenting when I saw the potential.” The field changes so quickly that being 'late' doesn’t really exist. “Within a year, most of what I know will probably be outdated. If you start now, you can catch up fast.”

Looking ahead, Stan thinks two things need to improve. First, the models. Most well-performing models today are still very general: they’re very good at everything, but not great at specific things like querying data or understanding specific domains. If the model itself understood the data and the domain better, the agent would need far less prompt engineering and extra context, and answers would be right much more often.

Secondly, hardware. “If GPUs get more energy-efficient and faster,” he says, “we can run these big models locally.” That would make things safer, less expensive, and easier to use in practice – especially if agents really become the main way people work with data.