Ask two offices what an active customer is
We have a running joke at our office. Ask what counts as an active customer, and you get a confident answer. Walk over to another team, ask the same question, and you get a different answer delivered with exactly the same confidence: an active customer is one we have sent a proposal to in the last three months.
There is no wrong or right here. Each definition works perfectly well for the people who use it, because they fill in the gaps with context. They talk to each other every day, they know which report finance trusts, and they know whose number to question. None of that is written down anywhere, and as long as humans do the work, it doesn't need to be.
An agent has none of that context. It has been trained on an enormous amount of general material, covering consumer retail, B2B sales, shipping and every other industry you can name. It has no way of knowing which industry you are in, or what “customer” means in your house. So it makes a reasonable guess, and it makes that guess separately in every chat.
Where most of us actually are
If you are responsible for data or AI in a large company, your situation probably looks something like this. Copilot, Claude or a similar tool has been rolled out, and people use GenAI on their desktops every day. Someone has built their own skill that handles one step of their work, and perhaps a small team shares it. Somewhere in one process, one part may already be agentic.
And it works. People get their ad hoc tasks done faster, and the pilots show the value is real. But almost everything is still started by hand. The agent does its job when someone presses the button; it hasn't yet become part of an automated workflow. Very few companies have any of this in production. Most have experiments and first versions.
I would describe Finnish adoption of GenAI as early laggers: not at the absolute front hype, but not far behind either. The companies furthest ahead are token-maxing and running five/six-figure token bills, and it's fair to ask whether that money is well spent. Not everyone has a billion to put into AI. The more useful question here is, what delivers business value sooner rather than later.
Which is why the question I hear most often is no longer whether this works. It's how to take one or two successful pilots and scale them to the company as a whole.
Three things decide whether it scales
Technically, turning a personal tool into a team tool rests on three things. The first is a shared way of working: skills and harnesses that carry the context of how we do things here and steer everyone to work the same way.
The second is data. Everyone needs access to the same data, its quality has to hold up to real decisions, and there has to be one source of truth behind it. Otherwise nobody can trust what the agent retrieves, or what they retrieve themselves.
The third has been argued over for years, often with open doubts about whether it's worth the effort: ontology. A shared agreement on what things mean in your company. This is where the first two either start working together or don't.
The data vendors have already woken up and are racing to create good technical solutions for building and providing an ontology for both people and agents. However, the main challenge has never been technical. It has always stalled on that same conversation about what an active customer is, or who counts as a customer in the first place.
Speed turns vagueness into errors
Before agents, a vague definition slowed things down. With agents, work moves so much faster that the same vagueness starts scaling errors instead, and some of those errors can be serious for the business. When one figure says 700 million and another says 20 million, the outcome isn't a better decision. It's more disputes, and more of the internal politics every organisation already has plenty of.
You won't see this in the pilot phase, because a single use case runs happily on its own definition. But run four pilots, each with a slightly different idea of the customer, and you are now maintaining the same information in four places. We know exactly what happens then. If people have to keep the same information up to date in multiple places, only one of them gets updated. That isn't laziness, it's incentives: if nobody ever asks for the other copies, nobody maintains them.
The good news is that the ontology doesn't have to be perfect. It never will be, and the first version is rarely right. Even a shared starting point people agree on improves agent results enormously, because it gives the agent the context that general training data can't. The definition can be refined and improved as you gain new information.
None of this is new. Conceptual and logical modelling have been around for a long time, and their whole purpose is to get definitions on paper rather than into one experienced colleague's head. You know that one person everyone contacts if they need information. Then they retire or change jobs, and all of a sudden nobody knows anything. So far organizations have not seen enough value in doing this work, hence it hasn’t been prioritized. Agents are changing that, because now the value shows up directly in the results.
Bottom-up and top-down at the same time
Scaling moves in steps: from person to team, from team to business unit, from unit to organisation. There is no single pipeline that fits every company. Use cases come from below, from the teams and units that can see what needs fixing. The basic definitions come from above, for example when finance decides how revenue is calculated here and shares that definition for everyone to use.
The top-down part is underrated. In the end, scaling means things get done faster because nobody has to stop and wonder whether something is allowed. Clear guidance says what kinds of things are fine to do, where the information you need lives, and who to ask when something is unclear. That speeds up getting started far more than it sounds like it would.
Keep the sceptic at the table
The technical building blocks are what makes this possible. How it actually gets used and develops is defined by culture. Does your team make room for experiments, or does the person who tries something new get beaten down by colleagues, as it is not how things have been done? On the other side, an overenthusiastic team that wants to do everything with GenAI needs its sceptic. That may be the person who points out that personal data shouldn't go into an unsecured/global open AI service, or that a handy little tool built on someone's personal licence is no place for company secrets. A hammer is a fine tool, just not when you need to drive a screw.
Personally I prefer to lead by example. I tell people which tools I use and how, and when someone asks whether I've thought about this or that, I take it on board. If every objection is heard as an attack, you get politics instead of progress.
Nobody has the answer yet
There is no final right answer to all this at the moment, and there can’t be when the ground shifts every three months. As I write this, TypeSafe AI has just launched Jev, a new model designed to automate, not to assist. Hence my question is: how do you make sure a use case that works today is still viable a year from now, on a new model with its own weights and its own way of solving problems?
We know which fundamental building blocks are needed, and the best part is that they are familiar: definitions, data quality and shared rules. Companies that kept their data in order long before AI are now moving much faster than competitors. With solid ground under your feet, it's easier to run. The work is laborious, but it isn't complicated.
We move the boundary of knowledge forward in increments, a bit like research, where everyone adds a little to what we collectively understand. What is most valuable right now is sharing the knowledge with peers. “We tried that, it didn't work, so we did this instead.” You won't find that in any report.
Your agent will never know what you know. Not unless you write it down.
