What you will have
At the end of these steps you will have an authority map for one AI workflow. It lists each action the system may take, who approves it, what evidence they see, and what happens when they decline.
The workflow owner uses the map to approve the design. Engineers use it to set permissions, and operators use it to run the system day to day.
Before you start
Gather a small group and a few records.
- The workflow owner: the person accountable for the business result.
- The people who approve today: whoever signs off on this work now, before any AI is involved.
- An engineer: someone who knows which systems the workflow will read from and write to.
- The current procedure: a written description, or a walk-through recorded as notes.
- A handful of real cases: routine ones and difficult ones, with sensitive details removed.
Human approval is part of the workflow design. It needs an owner, a review interface, and a recorded decision, so plan it with the same care as the integration.
Step 1: List every action the system may take
Begin with the action the system may perform. Write each one as a verb and an object, such as “read the customer record” or “send the reply”.
Reading a record, drafting a response, and changing an authoritative record carry different responsibilities. Keep them as separate lines, even when one tool performs all three.
Include actions that touch other systems: sending messages, creating tasks, updating the CRM, or posting to the accounting system. An action left off the list has no approver.
Step 2: Rate each action by its consequence
For each action, ask what happens if it is wrong. Consider who is affected, whether the action can be reversed, and how quickly an error would be noticed.
Actions that only read or prepare work usually carry a low consequence. Actions that change a source of truth, reach a customer, or move money carry a higher one.
Record the rating beside each action. The rating decides how much review the action needs.
Questions that set the rating
- Can the action be undone, and by whom?
- Does it reach anyone outside the business?
- Does it change a record other systems rely on?
- Would an error be caught by the next step, or only later?
Step 3: Name the approver for each consequential action
An agent’s permissions should describe the distinction between preparing work and acting on it. Name the person who approves consequential actions and changes to those permissions.
Use a named role and a named person, with a backup for absences. “The finance team” is a group; “the accounts payable lead, or the controller in their absence” is an approver.
Agents work only inside these permissions. The production release itself also needs a named approver on your side.
Step 4: Specify the evidence in each review request
A review request should include the proposed action, its source records, and the applicable business rule.
The approver also needs the limits of the result. Missing information and unresolved exceptions belong beside the proposal.
Write the request format down. A useful test is whether the approver could decide without opening another system.
What a review request contains
- The action proposed, stated in plain words
- The records the proposal is based on, with links
- The business rule applied, and its version
- Anything missing, uncertain, or outside the usual pattern
- The choices available: approve, decline, or return for revision
Step 5: Define what happens when approval is withheld
The workflow should preserve the original record and identify the next responsible person. The team agrees whether revision, escalation, or cancellation follows.
Record the reason for each declined request. Those reasons show where the rules, the data, or the system need attention.
Set a rule for requests that wait too long. Name who is notified, and confirm that nothing proceeds without a decision.
Step 6: Test both paths before production
Run the real cases from your preparation through the workflow. Include cases the approver should accept and cases they should decline.
A release is ready for review when both accepted and withheld decisions behave as specified. Check that each decision is recorded with the approver’s name and the evidence they saw.
The workflow owner reviews the results and approves the release, or returns it with notes.
Step 7: Review the boundary when the system changes
New tools, models, or integrations can change the actions available to an agent. A person approves those changes before they enter production.
Keep the authority map with the runbook. Update it in the same change as the permissions, so the document and the system always match.
Widening an agent’s authority is a decision, made by the named owner on recorded evidence. It never happens as a side effect of an update.
Check your work
Read the finished map with the workflow owner and ask these questions.
- Does every action that changes a record, reaches a customer, or moves money have a named approver?
- Could an approver decide from the review request alone?
- Is there a recorded path for every declined request, and for requests that wait?
- Do the permissions in the system match the map line for line?
If an answer is unclear, return to the step it concerns before the workflow connects to live systems.
Put it to work
Our Custom Agentic Systems service builds workflows around this kind of authority map. Agreed acceptance criteria connect the design to its evaluation, and your named approver accepts each release.
For agents already running, Agent Assurance adds evaluation, tracing, and approval boundaries in production. People continue to approve consequential actions.
The approval point belongs in the acceptance test as well. Read Agree the test before the build to see how the two fit together.