When AI Agents Enter the Process: How Documentation Architecture Must Change

Sep 30

10 min read

Most operational documentation still assumes that a person is performing the process. A procedure may say that Operations reviews a case, Compliance assesses the risk, Finance releases a payment or the MLRO approves an exception. Behind those statements sits an implicit operating model in which a human receives information, applies a rule, makes or recommends a decision and records the outcome.

AI agents begin to change that model because they can do considerably more than automate an isolated task. An agent may interpret an instruction, retrieve information, select between available actions, call another system, initiate a workflow, prepare or execute a transaction and determine whether an exception requires escalation. In some implementations, several of those steps may take place without a person interacting with each one individually.

Once that happens, existing documentation has to describe more than responsibilities allocated to named functions. It needs to establish what the agent is authorised to do, under which conditions it may act, which systems and data it can access, where human authority remains necessary and what evidence should exist after the action has been completed.

The documentation challenge is therefore not simply to add an AI section to an existing policy. It is to make sure that the documentation architecture still reflects the way the process actually operates.

Existing procedures often hide an assumption about who is acting

Consider a relatively ordinary statement in a payment operations procedure:

Eligible payouts are reviewed and released by Operations.

The instruction appears straightforward until an AI agent is inserted into the process. A human may now instruct the agent to process eligible payouts, after which the agent retrieves the relevant queue, applies predefined eligibility criteria, checks whether required information is present, identifies exceptions, calls a payment tool and prepares transactions for execution. Depending on the operating model, it may also be permitted to submit some transactions without further human intervention.

At that point, the original procedure no longer describes the process with sufficient precision. The phrase “eligible payouts” now raises questions about where the eligibility criteria are defined, who approved them, whether the agent is permitted to interpret them or merely apply them, and what happens when the available information does not produce a clear outcome. The same applies to execution: the agent may be allowed to prepare an instruction but not release it, or it may be permitted to release transactions only below a certain threshold or within a defined set of counterparties.

Questions also arise around actions that were previously assumed to sit naturally within a human role. Can the agent create or amend beneficiary details? Can it resolve conflicting information? Can it proceed when an external screening service is unavailable? Who can stop the process, and who owns the decision when an action was technically performed by software but within authority designed and approved by people?

These are not primarily questions about AI technology. They are questions about authority, control design and evidence, and the documentation framework needs to answer them accordingly.

Capability is not the same as authority

One of the most important distinctions in an agent-enabled process is between what the technology can do and what the organisation has decided it may do.

An agent may technically be able to access customer information, generate payment instructions, query a sanctions screening service, amend workflow status and communicate with external tools. That technical capability does not automatically give it organisational authority to exercise all of those functions autonomously.

A useful documentation model therefore separates three concepts: technical capability, meaning what the agent is able to do; permitted action, meaning what the organisation allows it to do within the process; and decision authority, meaning what the organisation allows the agent to determine without further human approval.

The distinction becomes important very quickly in practice. An agent may be permitted to calculate a customer risk score but not to decide whether an exception to the methodology is acceptable. It may prepare a payment instruction while being unable to approve a new beneficiary. It may identify that Enhanced Due Diligence criteria have been met, but it should not necessarily have authority to waive a control or decide that incomplete evidence is sufficient.

If those boundaries exist only in system configuration, employees may not understand the actual operating model. If they exist only in policy language, while the system permissions allow the agent to go further, the documented framework and the technical environment are describing different realities.

For that reason, documentation and technical permissions need to be designed around the same boundary of authority.

The agent needs a documented operating boundary

Human roles usually sit within an established governance structure. Employees have job descriptions, delegated authorities, approval limits, access rights, escalation routes and management oversight. An agent performing operational activity needs an equivalent control boundary, although that boundary may need to be expressed differently.

For a payment-related process, the documentation may need to specify whether the agent is allowed to identify transactions for processing, prepare an instruction, select a pre-approved route, use particular credentials or submit an instruction to a payment provider. It should also make clear whether any of those actions require a prior human approval and whether transaction value, jurisdiction, counterparty type or other factors change the agent’s permitted scope.

The same framework should define what sits outside that authority. An agent may be prohibited from creating a new beneficiary, changing settlement details, overriding a sanctions result, altering an approval threshold, operating outside designated jurisdictions or resolving particular exception types without escalation.

This is more useful than relying on a broad statement such as “AI-supported processes remain subject to human oversight”. That statement may express the intended governance principle, but it says very little about how the control actually works.

The more useful documentation questions are which actions the agent may perform, which actions it may not perform, where human approval becomes mandatory and under what conditions the process must stop.

Decision rights become harder to see

Traditional governance documentation often relies on a relatively simple division of responsibilities: one function prepares, another reviews and a designated role approves. Agent-enabled processes can introduce an additional layer between the original instruction and the eventual action.

A human may initiate the process, but the agent may interpret what that instruction means, apply criteria defined elsewhere, select the next step and call another system that performs the transaction. The operational chain may therefore look more like:

Human instruction → agent interpretation → tool or system action → operational outcome

This matters because initiating an action is not necessarily the same as making the decision embedded within it.

Suppose an employee tells an agent to “process all eligible merchant payouts”. The employee has initiated the task, but if the agent determines which payouts qualify as eligible, the decision is partly dependent on criteria applied by the agent. The documentation should therefore establish who defined those criteria, who approved their use, who owns changes to them and what happens where the agent cannot apply them with sufficient certainty.

Without that clarity, accountability can become blurred across the process even when every individual technical event is logged.

Human approval needs to remain a meaningful control

A common response to agent-enabled processes is to preserve a human approval point. In many cases that is entirely appropriate, but the presence of an approval button does not, by itself, demonstrate meaningful human oversight.

An agent may gather the relevant information, apply the methodology, prepare the recommendation, highlight supporting evidence and present the employee with a proposed decision. If the employee’s role is reduced to routinely confirming that recommendation, the process technically remains human-approved while the substantive decision-making has already moved elsewhere.

The documentation should therefore explain what the human approver is expected to assess. Depending on the process, this may involve verifying particular facts, reviewing specified risk indicators, examining exceptions, considering information that is not available to the agent or determining whether the recommendation remains consistent with the organisation’s risk appetite.

The organisation may also need to understand how often human reviewers disagree with the agent and why. A very low override rate could indicate that the automated process is performing well, but it could equally suggest that human review has become a largely procedural confirmation step. Documentation cannot determine which explanation is correct, but it can define what meaningful review is supposed to involve so that the control can later be tested against that expectation.

Access control becomes part of the documentation architecture

Agentic processes also make the relationship between procedural documentation and access control considerably more important.

A human employee will usually interact with a system through an individual identity with defined permissions. An agent may instead use service credentials, delegated tokens, API access or tools exposed through an integration layer such as MCP, potentially across several systems in the same process.

The relevant questions therefore extend beyond ordinary user access. The organisation needs to understand which identity is associated with the agent’s actions, what data it can retrieve, whether it has read-only or write access, whether it can create transactions or amend information, and whether the same credential can be used both to prepare and execute an action. Where the agent can call another tool or another agent, the organisation also needs to consider whether that downstream capability effectively expands the original permission boundary.

These questions are not solely cybersecurity matters because system access determines what operational authority the agent can exercise in practice. A procedure stating that an agent cannot perform a particular action provides limited protection if the technical access model allows exactly that action. Conversely, tightly designed permissions may enforce an important operational boundary more reliably than policy language alone.

The documentation framework therefore needs to connect procedural authority with the access model that supports it.

The most important control may be where the agent stops

Automation is normally designed around the expected path through a process, whereas the quality of the control framework often becomes clearer when that path breaks down.

An agent may encounter incomplete information, inconsistent customer data, an unsupported jurisdiction, an unusual transaction pattern, conflicting instructions, a system outage or an unexpected response from an external tool. It may also reach a situation that does not fit comfortably within the rules it has been given.

Documentation should define how those situations are handled rather than leaving the agent’s response implicit. Some exceptions may permit an automated retry, while others may require human review or immediate escalation. Certain circumstances may justify stopping the process entirely until a designated person has assessed the case.

This makes the stop condition an important part of agent governance. The organisation should be able to describe not only what the agent is expected to do when the process works normally, but also the point at which it is no longer authorised to continue without intervention.

That boundary becomes particularly important where an agent can create external consequences, such as communicating with a customer, initiating a payment, restricting an account or escalating a case into another operational process.

The evidence model changes as well

Traditional operational evidence often assumes a relatively simple event: a named user performed a particular action at a particular time. Agent-enabled processes can require a more detailed audit trail because the path from instruction to outcome contains additional stages and may involve several systems.

For a material decision or action, the organisation may need to retain enough information to understand who initiated the task, which agent acted, what instruction it received, which systems or tools it accessed, which relevant rules were applied, whether an exception occurred, whether human approval or override was involved and what final action resulted.

The exact level of detail will depend on the process and its risk, but the underlying objective is consistent: the organisation should be able to reconstruct a material event after it has happened.

An audit trail containing only the final transaction may prove that an action occurred without explaining why it occurred. At the other extreme, retaining every intermediate technical event can create enormous volumes of data without producing useful evidence. The documentation therefore needs to identify which records matter for accountability, investigation and control testing rather than treating technical logging and evidential sufficiency as the same thing.

As the operating architecture changes, the evidence architecture needs to change with it.

Existing documents may no longer describe the real process

Introducing an agent rarely affects only an AI-specific policy. More often, it exposes assumptions embedded throughout the existing documentation framework.

An Access Control Policy may have been written on the assumption that access belongs to employees and conventional service accounts. A Payments Procedure may assume that a human manually selects and submits transactions. A Customer Onboarding Procedure may allocate tasks to Operations without distinguishing between human and automated execution, while an Approval Matrix may identify who can authorise a decision without explaining what an agent may do before or after that approval.

Other dependencies may emerge in incident and third-party documentation. An Incident Procedure may not distinguish between a system malfunction and an agent operating beyond its intended boundary. An Outsourcing or Third-Party Framework may not capture reliance on external models, agent tooling or infrastructure embedded within the operational chain.

The resulting problem is broader than an outdated AI policy. The organisation may now be operating a process that differs materially from the one described across several parts of its documentation framework.

The appropriate response is not necessarily to create a separate policy or procedure for every agent-enabled process. In many cases, the better approach is to identify which assumptions have changed and update the existing documentation where those changes affect authority, process, controls or evidence.

A practical documentation test for agent-enabled processes

A useful review can begin with seven operational questions:

Who authorised the agent to act within this process?
What actions is the agent permitted, and prohibited, from performing?
Which decisions still require human approval or intervention?
Which systems, data and credentials can the agent access?
Which conditions require it to stop or escalate?
Who can override, suspend or change its authority?
What evidence allows the organisation to reconstruct what happened?

The value of these questions is that they move the discussion away from generic statements about AI governance and towards the design of a process that can actually be governed, tested and evidenced.

Documentation needs to follow the real chain of authority

The introduction of AI agents does not remove accountability from the organisation, but it can change the route through which actions are initiated and decisions are executed.

A process that previously looked like:

Employee → System → Action

may now operate more like:

Human instruction → AI agent → tool → system → action → human review or exception handling

Policies will still need to establish principles, methodologies will still define decision criteria, procedures will still describe operational steps and approval structures will still allocate authority. The difference is that the documentation must now explain how the agent moves between those layers, what constrains its actions and at which points responsibility returns explicitly to a human decision-maker.

The objective is not to document AI simply because AI is new. It is to ensure that the organisation’s documentation continues to describe the operating model accurately enough for people to understand who or what is acting, under whose authority and within which limits.

Key takeaway

When AI agents move from assisting employees to acting within operational processes, documentation architecture needs to evolve with the operating model.

The relevant questions are no longer limited to what a procedure instructs an employee to do. The framework also needs to establish what the agent is authorised to do, which decisions remain human, how access is controlled, when the agent must stop, who can intervene and what evidence remains afterwards.

A well-documented agent-enabled process should make the chain from human authority to agent action to operational outcome visible and traceable. Once software begins acting inside the process, knowing what the system is capable of is not enough; the organisation also needs to be able to demonstrate why the action was permitted, where the agent’s authority ended and how that boundary was enforced.