The four levels of enterprise AI

Developalooza 2026, Rebel, Oslo. Keynote by Kristian Mella, CIO and co-founder of Appfarm.

The first session had been about building faster. Kristian kicked off the second session, on the AI that runs inside the apps once they are built: a site worker talking his daily report into a phone instead of typing it, an agent checking every deviation against the contract before the reporting deadline passes, and Claude booking a resource without anyone opening the app.

Personal productivity is not process productivity

Everything being sold as AI right now falls into one of two buckets.

A salesperson researching prospects and drafting pitches in Claude is real value. But that value lives inside one person’s day and it is usually ad hoc. Onboarding a new employee is a different type of work. So is managing change orders on a large project. Those span several roles, touch several systems, and run for weeks.

Kristian’s take on the difference: personal productivity makes people faster, process productivity changes what the company is capable of.

The model is the commodity

At the bottom of the stack sit the models, and they are interchangeable now. You can swap Anthropic for OpenAI or Mistral and carry on.

What is not interchangeable is everything stacked above them: your data, your processes and your documents, the live state of the business, and the domain instructions that mean nobody has to write the prompt from scratch because the prompt for the task is already there. Above that again are the points where a person looks at what the AI did and decides whether it goes ahead, which means someone has to design and build that loop and the interface it happens in.

None of that is a model capability. It all sits in the platform.

From automation to agents

Kristian presented four levels of enterprise AI, progressing from left to right. Each level is more autonomous than the last and the governance demands change accordingly.

1. AI automation is one or more AI steps in a sequence. You photograph something, the model analyzes it and the form comes back filled in. It saves time and stays fairly predictable.
2. An AI assistant sits on top of documents or data and answers questions in context. Most companies already have one. Ask how a project went last week while you are inside that project, and it knows which project you mean.
3. MCP is an API for agents. Where the other three levels are about how much the AI decides, MCP is about where the call originates: Claude or Copilot reaches into your Appfarm apps rather than the other way around.
4. Agentic AI is goal-oriented. You hand it a goal, and with access to data and tools it works in iterations and reports back once it is done.

The value goes up as you move right, but so does the risk. Level one needs testing. Level four needs bounded autonomy, which means permissions and a person in the loop on the steps you cannot undo.

Six demos from a construction company

Rather than describe the levels, Kristian showed them running. Appfarm built three apps in one Solution for a fictional construction company: Project admin for planning and resourcing, SiteCheck on mobile for field workers doing inspections and daily reports, and a vendor portal with scoped access for external vendors.

Voice capture in the field

Daily reports are mandatory on these projects, and nobody wants to type them on site. A worker talks, Whisper transcribes, and Anthropic runs a prebuilt instruction over the transcript to pull out what was done, what the weather was, and anything that deviated. In the demo it found three deviations, two of which were real and one duplicate.

The change order agent

Under NS8407, the standard Norwegian construction contract, you have fourteen days to report something that will hit your timeline or your cost. Miss the window and you lose the right to compensation. An agent sits behind the deviation reports, the inspections and the vendor inquiries, knows which project each one belongs to, and has the contract and the plan. When the ground conditions on the demo site turned out to be water and soft clay rather than what was expected, it flagged it and put a person in front of an estimate.

The tender agent

Bid managers lose days to tenders, first working out whether to bid at all and then filling in a requirement matrix they have effectively answered ten times before. The agent reads the new tender, checks the requirements against ten previously won ones and against who is actually available with the right certificates, and comes back with a recommendation. In the demo it flagged one requirement as at risk and three as uncertain, found the rest compliant and recommended bidding. It then pre-filled the matrix and generated the document to send.

The assistant that can act

A chatbot over your data is not new, but this one lives inside the resource planner people already work in and it can act rather than only answer. Asked whether an HSE resource was free next week, it answered from the data and then booked them. It also runs as you, so if you cannot see payroll, neither can it.

The resource planning agent

This one runs in the same resource planner but is given a great deal more latitude. Handed a project rather than a booking, it read the contract, worked out which roles were needed, checked availability and built a staffing plan, logging each decision and why. It stopped on a site supervisor who was only partially available for the period rather than quietly booking them anyway.

MCP

The first five demos all run inside Appfarm. This one starts outside it. Appfarm can expose Solution data and actions as MCP tools, which means tools like Claude can call them directly. Kristian had Claude open on one screen and the resource planner on the other. He asked Claude which roles looked like a risk for the project period, and Claude answered by reading the same booking data the app runs on. He then told Claude to book Ingrid for the period, and the booking appeared in the resource planner beside it a second later, with nobody touching the app. Those tools run under the permissions of whoever is signed in, so pointing Claude at them does not let it see or do anything that person could not already do themselves.

Two kinds of agents

Kristian split the agents in these demos into two types. The change order agent is a long-running agent, which sits and listens and acts whenever a deviation or a vendor inquiry arrives. The resource planning agent is a planning agent, which takes a task, works until the task is done and then stops.

Most of these demos had a person in the loop. Kristian said that will not always be necessary, but it is where things sit today.

Getting it built is easy. Getting it safely into production is not.

Kristian ended on the same point Marius had made earlier in the day. Building something that works has never been quicker. Putting it into production with permissions, boundaries and no code of your own to maintain is the part that still takes a platform.

Someone asked afterwards why you would use an agent at all for a workflow where you already know every step. Kristian’s answer was that you would not. Deterministic automation is still most of the work, and most of digitalization still lives there. The change is that in a twenty-step process, fifteen of those steps stay fixed and perhaps five can now be skipped with AI. A fixed process is still worth building as a fixed process, and then exposing through MCP so an agent can call it.

Part of our series of recaps from Developalooza 2026. Read the rest of the series, or sign up to our newsletter so you don’t miss an invitation to next year’s edition.