AI agents in the enterprise: what must an agent understand before it acts?

The move from generative AI to agentic AI changes the relationship between an organisation and its AI. A system that no longer just returns an answer can take a goal, use tools and carry out a sequence of actions. Once AI starts acting inside business systems, the important question is no longer only what it can access, but what it is acting on the basis of, and who gave it the authority to do so.

The market is already moving in this direction.

As autonomy rises, the requirements for oversight, evidence, authority and limits on action have to become more explicit as well.

A technical permission is not a business authorisation

It is possible to define precisely which systems an agent may connect to, what information it can read and which actions are available to it. Those are access and permission mechanisms, and they are a basic requirement, but they answer only one question: what the system is technically able to do.

Suppose an agent has permission to update a delivery date. Technically, that is a simple action. In business terms, before such a change you need to know whether the customer has already agreed a different date, whether the contract allows the change, whether it affects another project, and who is actually authorised to approve it in this case.

A permission gives access to a button. A business decision demands more: identifying what is being acted on, understanding its state and history, knowing what information the decision rests on, identifying who holds the authority, and knowing when to stop.

Five questions the architecture must be able to answer

What am I acting on?

Identity is the starting condition. The same project can appear under one name in the ERP, under a different number in the operational system and under an internal nickname in documents. A person who knows the organisation knows these are the same object. To a system, they are separate records until the link between them is defined. The architecture has to hold a consistent identity even when the sources themselves are inconsistent.

What state is it in, and how did it get here?

A single status almost never tells the whole story. A project can be marked In Progress while it waits on a decision that puts its deadline at risk, and an order can show as Open while in practice it is stuck with a supplier. Understanding a state takes a sequence of events, decisions and changes over time, not just the latest value in a field.

On what basis do I know?

The more an agent can do, the more provenance and evidence become part of the decision itself. The system has to know where the information came from, when it was last updated, whether it contradicts another source, and what was available at the moment the decision was made. An audit trail is not only a tool for investigating after an incident. It is part of being able to explain and review, in real time, why an action was reasonable.

Who has the authority to decide?

Ownership and authority are not the same thing. A project manager can be accountable for the progress of the work without being authorised to approve a contract change, and an operations lead can own a task without being the one who approves a financial exception. So the model has to represent not only who is handling something, but who may make which kind of decision, and under what conditions.

Am I allowed to act, or should I stop?

Sometimes the right action for an autonomous system is to do nothing. When information is missing, sources contradict each other, a risk threshold is crossed or human authority is required, the architecture has to let the agent stop and escalate to the right person. Human in the loop is not just a stopgap until AI gets smarter. In some situations the person is the source of authority and accountability, which makes them part of the right architecture even in an advanced system.

The same direction shows up in broader governance frameworks. NIST stresses that governance and documentation should be a continuous part of an AI system's lifecycle, not a control layer added at the end. Project NANDA recently proposed levels of agent autonomy that pair more independence with less real-time human supervision, and therefore with stronger governance and accountability. The common thread is simple: the more a system does, the more explicit an organisation has to be about the limits it operates within.

Operational context is the meaning. The operational model is the asset that holds it

This is where the terms need to be precise. Operational context is the meaning a system has to understand at a given moment: what the object is, what state it is in, what happened before, who is accountable, who is authorised and which exceptions apply. It is the context that lets information be interpreted within the work, not merely read.

The operational model is the asset that represents and maintains that meaning in a structured, lasting form. It holds the business entities, the relationships between them, their states, events, decisions, accountability and authority.

AI can help discover relationships, suggest updates and maintain parts of the model, but it is not the model itself. The distinction matters especially in an agentic environment, because the models and the agents will change, while the representation of the organisation has to stay consistent, governed and current over time.

Evidence does not end before the action

When a system only produces an answer, the interaction is relatively easy to see: a user asked and got an answer. An agent working over time can read information from one source, make a decision, act in a different system, wait for a new event and carry on from there. So it is not only the outcome that has to be kept, but the chain that led to it.

A suitable architecture has to make it possible to see what information was available at the time of the decision, where it came from, what authority allowed the action, whether a person approved a given step, and what changed as a result. That is how an audit trail turns from after-the-fact record keeping into part of the organisation's system of control and learning.

The same principle matters when the system does not act. If an agent stopped and escalated a decision to a person, it has to be clear what made it stop and what is missing for it to continue.

This is the layer HIVO builds

HIVO is the operational system of record for enterprise AI. It builds and maintains a shared operational model above the source systems, so that entities, relationships, states, events, accountability and authority have one representation that persists over time.

The aim is not to replace the ERP, the CRM or the core systems. Each remains the system of record in its own domain. HIVO's operational model holds the way those systems connect to the same work, and from it operational context can be supplied to people and to AI capabilities as needed.

Where AI agents come in, the architectural direction is that an agent should not have to work out on its own, every time, who is accountable, which source is authoritative or whether a particular action is within its authority. The model should let the system receive the context, the evidence and the controls it needs before acting, and know when the process has to pass to a person.

For more on operational context and how AI comes to understand an organisation, see What happens after the demo.

Before the first agent, ask a different question

The debate around agentic AI rightly focuses on capability: which model plans better, how many systems it can connect to and how many steps it can carry out. But as a system gains independence, technical capability is only one side of the equation.

Before an agent is allowed to act, you need to know what it is acting on, what state that is in and how it got there, on what basis it knows, who is authorised to make the decision, and whether in this case it may act or should stop. If the answers to those questions still live only in people's heads, a smarter agent does not necessarily solve the problem.