AI Agents in Document Workflows: Limits of Authority
The instruction ‘process this supplier message’ sounds simple until it leads to an action in the system. Finding the related contract, preparing a change request, updating the delivery address and notifying the supplier each require different permissions. Combine them into one vague task, and employees may struggle to tell what has already happened and what still awaits their decision.
Design an AI agent as a participant with a defined role: what it is assigned to do, which changes it may make, and who handles exceptions. We will explore that role through an illustrative request to change a delivery address. This proposed workflow can be tested in a pilot.
Define the task before granting autonomy
In its article on AI agents, InBase describes incoming document classification, routing, and draft preparation. These examples suggest a useful starting point for discussion: what preparatory work exactly does the organisation want to delegate to the system?
Anthropic distinguishes between predefined workflows and agents in which the model chooses the next steps and tools. It recommends starting with the simplest solution that meets the need. If the sequence is already known, establish why the model needs to make those choices.
A standard workflow can also call a language model, for example, to draft text. This does not make the entire process agentic. For the pilot, specify the concrete choice you are delegating to the model: identifying which materials are missing, or selecting the next permitted check depending on the result obtained.
In our example, the assignment could be to find the documents related to the message and prepare a proposed change for the employee responsible. The useful output is a complete request ready for review. Identify where employees currently spend effort: finding the contract, copying data or deciding who should approve the change. Test that task first.
Describe permissions as actions
OWASP links the risk of excessive agent autonomy to unnecessary capabilities, excessive permissions and too much freedom of action. Its recommendations include limiting tools to those needed, approving significant operations and checking authorisation in the systems that execute them.
For the pilot, turn the general 'access to document management' into a list of specific actions. Separately define reading materials, creating a draft, forwarding a request, and modifying current operational records. The model's instructions explain the task; system settings must enforce its boundaries. The supplier's letter is input data and does not in itself grant additional permissions.
- Read: only materials required for the assigned request.
- Prepare: a change proposal with a link to the incoming letter.
- Forward: the task to a designated process participant.
- Modify: only permitted fields after the required approval.
This initial outline should be refined with the process owner. Permission to register a request, for example, does not also grant permission to update supplier records or send an external notification.
Ask the team to demonstrate a prohibited action in the test environment, too. If the agent tries to modify a field outside its role, the system should reject the operation. Check that the operation was rejected and logged; the assistant saying it remembers the restrictions is not enough.
One message, several handoffs
Imagine a supplier requesting a change of delivery address in a current order. In our scenario, the agent helps find the order, match the message with existing data, and prepare a request. Verifying who made the request and whether they have the authority to ask for such a change remains a separate process rule; a matching company name in the text does not prove this.
Break the workflow into handovers. Employees can then see when the agent is gathering information, when it is waiting for a decision, and when the system has completed an authorised operation. For this illustrative pilot, we propose the following sequence:
- Receive. Save the letter and determine which order the request belongs to.
- Prepare. Show the current address, the proposed address, and the reason for the change.
- Forward. Direct the request to the employee authorised to review it.
- Execute. Apply the approved change and record the outcome of the operation.
The draft change request is a separate operational record. Creating it should not silently change the address in the order. If a decision requires a missing attachment or confirmation from the supplier, the agent can usefully prepare a request for clarification that identifies what is missing.
Approve a specific change, not a confidence score
The Microsoft Agent Framework describes a mechanism where a process sends a request to a human and awaits a response. For a tool requiring approval, calling it can create such a pause. This must be explicitly planned for: the mere presence of multiple agents in a workflow does not establish human control.
In our scenario, the approval screen should answer a simple question: what will change after confirmation? We recommend displaying the order, the old and new values, the justification, and a list of subsequent actions. Sending a notification to the supplier should also be indicated if it is part of the approved operation.
- Is the employee approving this exact address for this exact order?
- What happens if the data changes while the request is awaiting a decision?
For the second situation, require another check before execution. If a colleague has already updated the order, do not automatically apply the earlier approval to the changed record. Show the employee an up-to-date comparison so they can assess a specific proposal, rather than clicking an abstract ‘trust AI’ button.
Resuming work without creating a duplicate
Microsoft documents checkpoints that save workflow state for later recovery, including messages and pending requests. It also describes different storage options: state held only in process memory does not survive a restart. Checkpoints help resume the workflow; handling repeated operations in external systems requires separate planning.
Ask the team to test this scenario separately: interrupt the response after the operation has been accepted, resume the workflow and count the requests. A ‘resumed’ label in the interface does not establish whether the correct result was saved in the system of record.
Stopping needs a clear outcome too
A task marked ‘handed over to a person’ is useful only if it is clear who received it and what they need to do. Include the original message, completed steps, confirmed changes and the reason for stopping. State explicitly when an operation's status is unknown. The employee should not have to reconstruct the full history.
Decide which events the log needs for later review: who started the process, which tool was called, what the system returned and who approved the change. Set the scope of retained documents and access to the log separately. Recording operational actions does not require indiscriminately copying all correspondence into the log.
Also assign an owner to this role: an employee who reviews exceptions and decides whether the rules need to be changed. After expanding access, repeat the checks. Permission for a new operation must be accompanied by a clear reason and a method to evaluate its outcome.
Before the pilot, agree on a retry limit and a way to stop further actions. Test a routine request, a rejected approval, changed data and an uncertain outcome. To prepare for a discussion with IQusion, outline one workflow containing these branches and list the permitted operations. This defines a specific automation task and clear acceptance criteria.
Frequently Asked Questions
Is an agent needed if the approval workflow is already defined?
First, determine which part of the work requires choosing the next step based on the content of the request. For a predefined sequence, a standard workflow with a separate AI function may suffice. Adding agentic autonomy to the entire process is not mandatory.
What if an incoming message asks the agent to bypass approval?
Keep the established workflow and refer the request to the employee responsible. The text of an external message does not grant permission for additional operations. The systems that execute tool calls must enforce the restrictions; test that enforcement during the pilot.
What counts as success when the agent stops?
Define an acceptable outcome for exceptions in advance: a clear reason for stopping, no further unapproved actions, saved state and a task assigned to a specific person. Include the time spent resolving the exception when evaluating how quickly the overall process finishes.
