Our engineers find the tasks agents can take over today, and what that saves you
What it is
Finding out what to build, before you build it
Product Discovery is a plain idea with a slightly grand name. It means working out which of your tasks an agent can take over today, and what that is worth, before anyone starts building.
Every workplace has tasks that people repeat: the same form filled in, the same numbers moved from one screen to another, the same question answered for the tenth time this month. An AI agent can take that work over now. Not all of it at once, and not all of it equally well, which is exactly why the order matters.
Discovery is how you work out that order, and it is the step almost everyone skips. They pick whatever sounds automatable, build it, and find out afterwards that it saved nobody any time. Done properly it comes out as lower running cost, and a business that handles more of its own routine work.
You do not pour the foundations before the ground has been surveyed. Digging costs money. Digging in the wrong place costs a great deal more.
Watch the work
Sit with the people doing the job and see what actually takes their time.
Pick the one worth doing
Rank what you found by hours and by cost, so you start with the one that pays.
Build it, for real
One working tool, in daily use within days, measured against where you started.
Other people call it process discovery, opportunity mapping or a feasibility study. Same idea.
What we offer
Two weeks to find it. Days to build it.
Our engineers spend the two weeks on site, with the people who do the work. Building the first agent takes days, not months, and it goes to production when it is done.
That is the whole thing. No platform to buy first, no transformation programme, no eighteen-month roadmap. One loop, found properly and built properly, and a written map of the rest.
It is not a workshop
We watch the work happen at the desks where it happens. Nobody has to describe their own job accurately in a meeting room, which is a thing people are famously bad at.
It is not a pilot
What we build runs on your infrastructure and goes live. A pilot that lives in a demo environment never survives the handover to the people who were supposed to benefit from it.
It is not a platform sale
We are not selling you a platform to buy first. If the best candidate turns out smaller than you hoped, you get that in writing, and the map is yours either way.
What changed
A year ago this took months. Now it takes days.
AI agents are barely a year old as a concept. Before them, building an internal tool and getting it into production was weeks of work and often months: somebody had to write every screen, every integration and every test by hand. That cost is what kept the list of things worth automating short, and it did the prioritising for you.
Agents have changed how applications get built. The same tool now gets built and deployed to production in days. Which is why the question worth spending real time on is no longer whether you can build it, but which one you should build.
Same tool, same production standard. The build stopped being the part that takes the time.
Why do it
Most of this still runs on spreadsheets and shared folders.
Walk into almost any organisation and the real operating knowledge sits in Excel sheets, SharePoint folders and a handful of people's heads. That was never anybody's failure. Until now there was no way to turn knowledge in that shape into software without a project big enough to need its own budget line.
AI agents changed that, and in most businesses the opportunity is larger than anyone has counted. Discovery is how you find the loops with the most hours and the highest error cost behind them, so the first thing you build is the one that pays for the next.
Ranked by your hours and your error costs, so the order can be defended.
Who does it
The engineers who build the platform are the ones who do the discovery.
Product Discovery is delivered by our own engineers, the same people who build the data platform. Not a research team, and not a partner network: whoever sits with your operators is whoever writes the code.
That matters more than it sounds. Discovery only works if the person watching the work can tell, on the spot, whether the data underneath will hold up. Split that across two firms and you get a report instead of a working agent.
We are based in Stavanger, we come to you, and we work in Norwegian or English. The people you meet in week one are the people who are still there in week four.
What we look for
Five shapes that keep showing up
We have yet to walk into an organisation that has none of these. They are easy to miss from the inside, because from the inside they are not problems, they are just how the work gets done.
-
The copy-paste loop
A person reads a document and types what it says into another system. Invoices, lab results, inspection reports, permits. High volume, low judgement, expensive on the day it goes wrong.
-
The Monday-morning report
The same report, assembled by hand, from the same five systems, every week. Nobody owns it, everybody needs it, and the mistakes in it get tolerated because that is just how it has always been.
-
The reconciliation
Two systems disagree. A person decides which one is right, again and again, on gut feeling, because the rules that would settle it were never written down.
-
The question queue
The same forty questions, asked of the same three people, answered from memory and a folder nobody else can find.
-
The handover
Shift to shift, project to project. What gets written down is a fraction of what was known, and the rest walks out of the building at the end of the day.
Why these hold up
An agent is only as good as what it stands on
A demo answers from whatever it can reach. A production agent has to answer the same way twice, show where the answer came from, and stop when it is out of its depth. That is not a prompt problem. It is a data problem, and it is the one we have spent years on.
Which is why product discovery and the data platform are the same conversation. The agent is the part people see. The model underneath is the part that decides whether it survives contact with an auditor.
Grounded in your model
The agent queries the same ontology your reports do: assets, processes, events, and the relationships between them. It is not guessing which of the four asset lists is the real one.
Every answer has a trail
Lineage on every value it touched. When somebody asks where a number came from, there is an answer instead of a shrug.
It stops at the gate
Anything that changes a record, sends a message or moves money waits for a person. The agent drafts. A human commits.
It is checked against real work
Before it goes near production it runs against cases your team already handled by hand, and we compare. The same harness catches it later, when it drifts.
It runs where your data lives
Your cloud, your servers, or our own Nordic infrastructure. Nothing has to leave the country for this to work.
What you get
What is on the table at the end
- A ranked map of your own work: every loop we found, costed in your hours and your error rates.
- The ranking, with reasons: the order still holds up when somebody asks why that one goes first.
- One agent in production: you pick the loop from the ranking, we build the agent that runs it.
- The code, and the right to run it: on your own infrastructure, with us or without us.
- A number you can defend: the week-one baseline, the number after, and the method in between.
The method in full
We wrote down how we do this. All of it.
The whole method is in our documentation: the shapes worth looking for, how to score a candidate, how the two weeks run, and the ways it goes wrong. Free to read and free to use. If you would rather run it yourself, everything you need is there. What we sell is the doing, not the knowing.
Product discovery, end to end
The five shapes, the five tests for scoring a candidate, how the two weeks actually run, and the failure modes.
Read the documentationWhat an AI agent actually is
Why an agent given a model of your operation reasons better, and far more checkably, than one given raw numbers.
Read the documentationChoosing a first project
How to pick something narrow enough to finish and valuable enough to fund the next one.
Read the documentationMeasuring the return
Taking a baseline that survives scrutiny, and proving afterwards that the thing actually worked.
Read the documentationStart with the map.
Two weeks, on site, with the people who actually do the work. If you already suspect which loop is costing you most, you will find out whether you are right.