The next step in data operations: shifting focus from execution to impact

🇫🇮 The original version of this interview in Finnish can be found using the language switcher on the top right corner.

An interview with Mikko Sulonen

Mikko Sulonen, CTO and data architect at Recordly, has spent years working hands-on with modern data platforms and large-scale transformations across industries. In this conversation, he explains what agentic data development means and how it may change the way data teams work and collaborate with business leaders.

What problems does agentic data development solve in organizations today?

– Above all, it solves the challenge of scaling data work from several angles. On the one hand, it effectively adds extra hands to data teams. More importantly, it enables teams to shift their focus to higher-value work.

For example, certain types of support and ticket-based questions can, to some extent, be handed over to agents:

• “Where does this number come from?”

• “How was this calculated?”

  And up to a certain point even: “This number is wrong” including investigation and, in some cases, suggestions for fixes.

When this kind of investigative work decreases, people can focus on more valuable and new problems.

If you had to explain agentic data development to a non-technical business leader in one sentence, how would you describe it?

– Data development is about getting the right information to the right place, at the right time, and in the right form. Data development isn’t always done by a human. In suitable tasks, it can be done by an agent, meaning a machine. This isn’t about replacing people, but about the fact that in some tasks, the doer can be an agent instead of a human.

When you talk with business leadership, how do they typically describe their frustration with data and analytics teams?

– Three things come up repeatedly: speed, trust, and transparency.

• Speed: responsiveness and delivery speed. When specific data is requested, how long does it actually take to deliver?

• Trust: is the data correct, does it stay correct, did it work today and will it work tomorrow? What about month-end, quarter-end, year-end? In many organizations, there’s still a lot of gut feeling and mistrust toward the numbers.

• Transparency (or visibility): data work is too often a “black box” inside a separate data team. Something is requested, then nothing is heard for weeks, and eventually something comes out — in the worst case through tickets. Leadership and the business want to see what’s happening and why.

There’s also a need for dialogue on both sides about how a business need translates into data:

“You need an answer to this; how does that show up in our data, and where does it come from?”

How is agentic data development different from simply using AI to make data work faster or cheaper?

– “Just making things faster or cheaper” is a fairly narrow way of looking at it. Of course those things can be measured, but what really matters is that the level of abstraction increases.

We’ve seen a similar shift before. For example, with cloud data warehouses, some previously manual maintenance work was abstracted away. That didn’t make data professionals unnecessary, but it allowed them to focus on more valuable and harder-to-define problems.

With agents, we’re facing the same situation: the tasks being automated are just “one level higher” than before. A question like “Where does this number come from?” might take a person half a day to figure out, while an agent can handle it efficiently and also explain the answer to the user.

If you focus only on speed and cost, many benefits are left unrealized. People get to focus on the work where they actually add the most value.

And the work doesn’t end. I’ve never seen a finished data platform. Once the basics are in place, new questions emerge, such as forecasting, competitor analysis, or “what if” scenarios.

Mikko Sulonen, CTO and data architect at Recordly

What kind of impact have you already seen in practice when agentic workflows are introduced?

– A concrete example is a migration scenario where there are tables, views, and calculations produced in an old way and new versions built using a new approach. A raw comparison produces no value on its own; value only emerges when differences are found and fixed so the end result is identical.

For an agent, a “raw comparison” is trivial. You give it the formula for how the comparison should be done, where the old and new versions are located, how results should be stored, and what should be reported. Comparing hundreds or thousands of tables is natural for an agent, while for a human it would be tedious, manual scripting work.

The next step, that is why the differences exist and how they should be fixed, still requires a human. An agent can help, but people make the decisions: is the difference acceptable, what caused it, are there generalizable fix patterns? This is where focus shifts to the value-producing goal: ensuring the migration outcome actually matches.

Which tasks typically decrease or disappear, and what becomes more important instead?

– I don’t think work disappears. Instead, the focus shifts. When agents can handle a lot of daily small tasks and investigations, people get more time for planning, evaluation, and longer-term work.

This is again about raising the level of abstraction: when you don’t have to constantly put out fires by hand, your perspective lifts beyond what’s right at your feet.

Are there roles whose content changes significantly as a result of this development?

– A role that’s purely technology-oriented, whether it’s a data engineer, BI analyst, or something similar, may lose some of its relative importance.

There will always be a need for top-tier technical experts; that won’t disappear. But the ability to see across silos, communicate, and understand the bigger picture becomes even more important: what’s really going on here, and what should be done? Technical detail doesn’t disappear, but its relative weight may diminish.

What skills or mindsets are most important for teams working in this kind of operating model?

– Business understanding and understanding the organization, including its culture. Language models “understand” SQL and technical specifications, but they don’t understand organizational culture, decision-making processes, or business problems in the same way.

Put simply: where there are lots of people, there’s lots of room for humans. Where there’s code and machines, there’s room for agents.

It’s also important not to view this short-sightedly as “jobs being taken away.” Work doesn’t run out by doing it. The right perspective is that this allows teams to raise their level of ambition: what can be done, and on what timeline.

Where should organizations start with agentic data development, and where should they be cautious?

– A good starting point is to begin with things that can be done using read-only access. That way, nothing breaks, yet a lot can be achieved.

For example, in cost optimization you can get very far with read-only access: which queries cost the most, how often they run, and whether there’s a cheaper alternative. Building a data catalog can also largely be done with read-only permissions.

Caution is needed when agents are allowed to execute and write. That’s when access control, test environments, and clarity around who does what, where, and with which permissions become critical.

If you could give one piece of advice to a business leader: what should they start focusing on differently in 2026?

– I’d emphasize openness, integrations, and interfaces even more. Agentic work and language models are evolving extremely fast. If data and systems are black boxes, or if information exists only behind user interfaces in a way agents can’t read, opportunities will quickly be missed.

These trends increase the importance of solutions being open, integrable, and aligned with common standards and practices.

Looking a few years ahead, what will data operations look like in organizations that adopt this approach early?

– What “Self Service BI” once promised will start to look modest in comparison. Its promise was largely about rotating dashboards. In the future, when data and processes are genuinely within reach (with permissions respected), you can request what’s needed at the moment it’s needed.

I don’t believe daily work will revolve around dashboards five years from now — maybe not even two years from now. Data will be available exactly at the point in the process where it’s needed, for a person or for a process.

Perhaps this is when we finally start delivering on the promises that earlier approaches aimed for, but which required enormous amounts of manual work.