AI
What changes when software acts on its own
When software acts on its own, the risk moves from output to action. A model that gets it wrong hands you a bad answer. An agentic system that gets it wrong has already sent the email.
What changes when software acts on its own is where the error lands. A language model that gets it wrong hands you a bad answer you can ignore. An agentic system that gets it wrong has already sent the email, credited the invoice or closed the case. The risk moves from output to action, and operations have to be rebuilt around that.
What separates an agentic system from a language model?
An agentic system gets two things a language model does not have: access to tools, and permission to decide the order itself. The model stops being a function somebody calls and becomes a process that runs until it judges the task done.
The loop has four steps, and they repeat until the system stops.
- Step 1
Reads the situation. The system pulls the state it needs: the case, the document, the archive, the account.
- Step 2
Chooses an action. The system decides for itself which tool to call, and with which arguments. This is where the sequence emerges instead of being programmed in advance.
- Step 3
Performs the action. The tool is called. If the action writes, it has now happened in a system outside the agent.
- Step 4
Reads the result and decides the next step. The system judges the outcome and returns to step 1, or stops.
Where does the loop stop?
The loop stops in three ways: the goal is reached, the attempts run out, or a person intervenes. The third stop condition is the one you design. The first two design themselves.
An agentic system with no defined third stop condition runs until it runs out of attempts. That is no safety mechanism. That is a timeout.
What changes in the risk picture?
The risk changes character, not only size. Four things move at once.
| With a language model | With an agentic system |
|---|---|
| The error is a bad answer you read | The error is an action already taken |
| You catch the error when you read the answer | You catch the error when the consequence surfaces somewhere else |
| The system crashes or answers oddly | The system does something plausible that is wrong, and does it with confidence |
| Uptime and response time catch operational trouble | Uptime and response time catch none of this |
The last row is the one that surprises most people. An agentic system in production usually has excellent operational numbers while it is getting things wrong. The system answers fast, it is up, and it makes bad decisions on time.
Why is the read-write split the cheapest control?
The split between reading and writing operations is the cheapest control because it can be set once and governs everything the system does afterwards. Let the agent read freely. Require approval for anything that sends, pays, deletes or changes data outside the system.
The control is cheap because it does not require you to anticipate the error. You do not need to know which wrong action the agent will propose. You only need to know which actions are irreversible, and that list is short and known in advance.
What we did in our own publishing agent
The publishing agent on apps.no reads the whole article archive, picks a subject, writes the text in two languages, makes the cover image and files everything in the CMS. The agent cannot publish. Every single write lands as a draft, and a person presses publish.
The boundary is worth defending because it has been tested. On 21 September 2026 the publishing agent produced two complete article drafts. Both had every mandatory field filled, a cover image attached, five FAQ questions and internal links that resolved in both languages. Schema validation in the CMS stopped one thing that day: an FAQ item whose answer field was missing because the key was misspelt.
Both drafts were rejected by a person. One because the evidence was second-hand, the other because the figures belonged to a different company than the blog belongs to. Neither of those two reasons has a field in a form.
Which controls have to be in place before volume goes up?
Four controls have to be settled before an agentic system runs at volume. None of them are hard to build. All four are expensive to retrofit.
Permissions. Each agent is its own identity with scoped permissions, short-lived keys and a revocation path that works in minutes. An agent inheriting a service account with broad permissions is a common way a useful pilot becomes an unacceptable production risk.
Logging. Every tool call is logged with the arguments it was called with, and with enough context to reconstruct a decision afterwards. The log is both the debugging and the documentation a public-sector buyer will ask for.
Reversibility. Every action the agent takes independently must be capable of being rolled back. If the action is not reversible, a person approves it.
Escalation. The threshold for fetching a human is written down and tested, and the human arrives with what has already been said.
How much of this pays off, and where it breaks, is worked through with figures in How Will Agentic AI Improve My Business?. Why the log is also the documentation regulators will ask for is covered in Agentic AI in a country with no AI law. What it costs to test this on products we own ourselves is covered in What building our own products teaches us.
Write down the irreversible actions first
If you are putting an agentic system into production this year, start with the list of actions that cannot be undone. Send the list to hello@apps.no. We will tell you which of them we would put behind an approval, and which we would let the agent do by itself.
About this article. Written by Espen Hareide, co-founder and partner at Apps. Anchor article for the pillar A new reality with agentic AI. The figures about the publishing agent come from Apps AS' own agent configuration and from the runs on 21 September 2026, read on 22 September 2026. The article does not draw on customer projects, and no customer figures are used.
FAQ
- How much autonomy should an agent have at the start?
- Less than it can technically handle. Start with the agent proposing and a person deciding, and record how often the two agree. Once agreement is stable over a few weeks, let the agent act independently on the least risky part first. The order matters more than the pace, because the first independent action is the one you have least experience with.
- What do we do if an action cannot be reversed at all?
- Then a person approves it, without exception. Money leaving the company, contracts that bind, data that is deleted and final messages to customers all belong in that category. The alternative is to build an intermediate state: the agent prepares the action in full and puts it in a queue, and the approval releases it. The wait is then short and the chance to pull back is real.
- How long do we need a person in the approval path?
- On the irreversible steps, always. On the rest, until you have numbers showing that the agent and the person agree. It is worth saying plainly that draft-and-approve is a perfectly real end state rather than a compromise on the way to full autonomy. At moderate volumes, human review costs less than people expect.
- How do we spot the agent doing something plausible that is wrong?
- Not through operational monitoring, which will show green. You need a measure of outcome rather than of completion: the share of cases reopened, the share of results corrected later, or spot checks where a person reviews a random sample of what the agent did. Without one of those three, you find out when the customer calls.
- Is the read-write split enough on its own?
- No, but it is the cheapest first step. The split does not handle an agent reading data it should not have seen, and it does not handle hostile inputs that get the agent to propose something wrong. Permission scoping and logging have to be added. The point of starting with the read-write split is that it can be set in a day and governs everything afterwards.
