Our findings in agentic automation from the Nordics Summit

At the Agentic Automation in Finance Nordics Summit I was one of the keynote speakers. My aim was simple: to share what we know from actual project experience, not visions or forecasts. Participants appreciated that approach, and after the session several told me this was exactly what they had been missing at similar events.

If that is so, the three lessons I shared from the stage are worth going through here.

Lesson 1: The success of agentic AI depends on the maturity of earlier technology #

In the race for the newest and the latest, it is easy to forget the obvious: new technologies come in layers, laid on top of earlier ones. Those layers matter a great deal in a game as data-heavy as AI adoption. If earlier systems cannot expose coherent data models to AI, or the integration options are limited, there is no point expecting miracles from the agentic AI sitting on top.

What the saying "agentic AI is the cherry on top" really means is that the success of LLM adoption depends on:

1. semantically structured, high-quality data sources, which depend on
2. open systems with robust, machine-accessible APIs, which depend on
3. an experienced team that got all of this in order in time, often before AI

That is what Vstorm project reality shows. The most successful projects are those where the data model was cleaned, corrected and stabilised years before LLMs took the spotlight. AI can only be executed well where back-end systems are ready to integrate new components. There, the AI part starts as an isolated island of functionality before it grows into something more comprehensive, such as Vstorm's AgenticOS.

Most of all, it works when the team on the client's side knows its systems and builds for the future. The success of an agentic project is often the fruit of their work from years before.

Lesson 2: Early adopters had it worst #

Everyone knows the AI space moves fast, but what does that mean for adoption projects? It means the tools and materials change while you build. If AI adoption were a race, those who started first would be worst off, because the engines kept improving and the runners-up got better equipment to catch up and take the lead. That is exactly what happens.

In Stockholm I shared the story of a multi-agent system a bank deployed in 2025 to support its clients financially. It was built with LangChain and with models that were far weaker at planning, context and tool use, so the architecture had to be spread across several workers orchestrated together.

The same engineering team told me that if they started the project in 2026, they would use a single agent and a simpler architecture. Why? Because everything has matured since: not only the models, but also the components for evaluating and observing their work.

Many people are surprised that systems shipped a year ago ran on orchestration frameworks that were still in beta. Pydantic AI (the framework Vstorm uses most often) reached version 1 in September 2025, and LangChain in October 2025.

So every system shipped before then was built on a beta version of these frameworks, and any system running on a stable version of LangChain or Pydantic AI is about a year old at most. That is not much time to gather experience with agentic AI and see the return on the investment.

Lesson 3: Structure matters far more than who wrote the code #

One way AI is reshaping the market is its ability to write code. Vibe coding works well enough that many people wonder where its limits are and whether code written by people is better or worse than code written by a machine.

The lesson we take from Vstorm projects is that the real question is not who writes the code, a person or a machine. It is what structure the code is written from.

Code written by engineers comes from their understanding, their mental model, of what the solution should become. There is a caveat: even a great understanding does not guarantee great code. That depends on how good they are at the job.

With machine-generated code, the result depends on how well the intent is defined. The code will reflect how clear the description, rules and guidelines were.

So the structure you start with, before any code is written, matters a great deal. It can take the form of written specifications or of mental models locked in someone's head. It pays to capture it well, both to make it clearer for people and to improve the code a machine produces.

The model is the smallest part of the lesson #

All three lessons are about what surrounds the model: the systems built before it, the tooling that matured around it and the clarity of what we ask it to build. That works in favour of organisations that have not started yet. The preparation is ordinary engineering work, and the tools available today are more stable than those the first adopters had.

From the projects we have delivered, we recommend three checks before any build starts:

1. Confirm that the systems the agent will rely on expose coherent data through machine-accessible APIs.
2. Choose the architecture for the models and frameworks available today, not for those available when the idea first came up.
3. Write down the intent, rules and guidelines clearly enough for either an engineer or a model to build from.

These lessons come from the same keynote as the companion post, What agentic AI is still taken for: three lessons from Stockholm, which covers what decision-makers still assume about agentic AI. If you work at a financial institution and want to check your systems against these three points, you can book a consultation with Vstorm.