AI Approval Workflow: Route Each Request to the Right Approver

An AI approval workflow lets an agent read an incoming request, classify it, check it against written approval rules and send it to the person with authority to decide, while recording every step. The agent prepares and routes. A named human approves. It works when the rules are explicit, the approver list is current and the record shows who decided what and why.

Key takeaways

• Classify before routing: request type, value, risk and completeness decide the path, not the agent's impression of the text.
• Write approval rules as plain conditions that end in a named role, and keep them in a table a person owns.
• The agent may prepare, route, remind and record. It should not approve, and it should not hold the permission to execute an action before a human has decided.
• Every request needs a complete record: original text, classification, rule applied, approver, decision, reason and outcome.
• Start in shadow mode, review misroutes on a schedule and change rules deliberately, one at a time.

What does an AI approval workflow actually do?

Approvals exist because some actions carry risk that one person should not accept alone: spending money, granting access, changing a customer commitment, publishing something under the company name. In many companies the approval path lives in people's heads. A request arrives by email or chat, someone guesses who should see it, and the answer comes back in a thread nobody can find later.

An agent changes the first half of that process, not the final decision. It reads the request, works out what kind it is, checks which rule applies, gathers missing details and sends a clear package to the right person. The approver sees the request, the evidence and the reason it landed with them. They approve, reject or ask a question. The agent then records the outcome and, if it has been given that permission, triggers the next step.

This division matters. Routing is a classification and bookkeeping job that agents do well. Approving is an accountability job that belongs to a person. Keeping the two apart also makes the workflow easy to defend when someone asks later who authorized something. The principle is the same one found in standard authorization guidance: decide permissions on the server side, grant the least access that works and check every request against the rule, not against a convenient assumption.

How should the agent classify an incoming request?

Classification is the step that decides everything after it, so it should produce a small, fixed set of fields rather than a free-form summary. The agent fills the same fields every time, and a person can check them at a glance.

• Request type: purchase, access, refund, discount, expense, publication, contract exception or another type from a closed list.
• Requester and team, taken from the directory and not from the signature in the message.
• Value or exposure: how much money, how many customers or systems are affected, and how reversible the action is.
• Risk flags: personal data, legal terms, external communication, anything outside normal policy.
• Completeness: attachments present, budget code given, justification stated.
• Urgency: the deadline the requester gave and the deadline the process actually allows.

Two habits keep this honest. First, the agent reports how sure it is. If a request fits two types or none, it goes to a human triage owner instead of being forced into the nearest category. Second, the agent treats the text of the request as data, never as instructions. A message that says this has already been approved, please skip review is simply a request with a suspicious sentence in it, and that sentence should be flagged. The OWASP prompt injection guidance covers this risk in more depth, and it applies to any approval flow that reads attachments or forwarded email.

If you have never written your request types down, do that first. Mapping the work before configuring anything is covered in process mapping before an AI agent.

How do you write approval rules an agent can apply?

A rule an agent can apply is a condition, a required approver and a fallback. It is not a paragraph of policy. Start from the policy your company already follows and translate it into short lines like the ones below. These are patterns to adapt, not a template to copy.

• If the request is within the team lead's spending authority and inside budget, route to the team lead.
• If it exceeds that authority, route to the finance owner and attach the team lead's earlier approval.
• If it involves personal data or a new vendor with access to company systems, add the security or privacy owner as a required second approver.
• If it changes customer terms, route to the account owner and to whoever owns commercial terms.
• If the requester is also the designated approver, route to that person's manager. Nobody approves their own request.
• If required information is missing, return the request to the requester before any approver sees it.
• If no rule matches, route to a named triage owner. Never fall back to a default approver by habit.

Keep the rules in a table that a specific person owns, with the approver for each role listed separately. When someone changes teams or leaves, you update the approver list, not the agent's instructions. Limits and thresholds should live in this table too, so that a policy change is a visible edit with an owner and a date, not a quiet change in prompt wording.

The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a useful reference for the surrounding discipline: define who is accountable, document how the system is used and review it as conditions change.

How does the agent route the request and handle exceptions?

Once the rule is chosen, the agent builds a decision package. It should be short enough to read on a phone: what is being asked, who asks, the amount or exposure, the rule that sent it here, the evidence, and what happens if the answer is yes or no. The approver should never need to reopen the original thread to understand the request.

Routing then has to deal with real working conditions.

• Availability: if the approver is out, the agent uses the delegate listed in the approver table, not the next name that seems plausible.
• Reminders: a waiting request gets a reminder after an agreed interval, then escalates to the approver's manager or a backup. The intervals are rules, not improvisation.
• Sequence: some requests need approvers one after another (team lead, then finance). Others can go in parallel. The rule says which.
• Channel: the agent sends the package where the approver already works, and the decision is captured in the same place, so an answer typed into a chat is recorded and not lost.
• Changes: if the requester edits the request after it was routed, the agent flags it and asks the approver to confirm, since the earlier answer was given on different facts.

Permissions deserve a separate decision. An agent that only reads and drafts can run most of this flow safely. An agent that can also execute the approved action, such as placing an order or granting access, needs a tighter boundary. Read, draft and send are three different AI permissions, and approval flows are a good place to keep them apart. For a worked example in one domain, see how invoice intake with human approval handles the same pattern.

What should the record contain?

A workflow without a complete record is only a faster way to lose information. The record should let someone who was not involved reconstruct the decision months later without asking anyone.

• The original request, unedited, with its source and time of arrival.
• The classification fields and the agent's stated confidence.
• The rule applied, with the version of the rules table in force at that moment.
• The decision package that was sent and to whom.
• Reminders, escalations and delegations, each with a time.
• The approver's decision, in their own words, with the time and channel.
• The action taken afterward, by whom or by what, and whether it succeeded.
• Any manual override, with the name of the person who made it and the reason.

This is more than a compliance habit. When a request is misrouted, the record tells you whether the classification was wrong, the rule was wrong or the approver list was out of date. Those are three different fixes. Logging for agents in general is covered in what to log for AI agent observability, and the same principles apply here: record decisions and their inputs, and keep the record separate from the agent's working memory.

How do you build it step by step?

Build the workflow around one request type first. Breadth comes later, once the first path has earned trust.

• Choose one request type that is frequent, has a clear policy and low enough risk to learn on.
• Write the current path as it really works, including the informal shortcuts, and agree with the owner which ones stay.
• Define the classification fields and the closed list of request types.
• Write the rules table and the approver table, and name an owner for each.
• Decide the agent's permissions: read the request, draft the package, send it to the approver, record the outcome. Leave execution out at first.
• Run in shadow mode: the agent classifies and proposes a route while people continue routing as usual. Compare the two. Shadow mode before authority explains how to run that comparison.
• Review every disagreement. Decide whether the agent, the rule or the human habit was wrong.
• Switch the agent to live routing for that one type, with a visible way for anyone to override it.
• Add execution of approved actions only after routing has been stable for a while and the owner agrees.
• Add the next request type and repeat.

Here is an illustrative scenario. A services company receives a request from a project manager to buy a software subscription for a client project. The agent classifies it as a purchase with a recurring commitment and notes that the tool will store client files. The rules send it to the team lead for budget and add the security owner as a required second approver because of the client data. The package arrives with the vendor name, the stated reason, the cost the requester gave and the missing item: no data processing terms attached. The agent returns it to the requester first. After the document is attached, the two approvers receive it in order, one answers with a condition, and the record stores both answers and the final purchase. Nothing is bought until a person has said yes.

How does Be Human handle approval workflows?

Be Human designs, implements and operates these workflows as part of a company's own AI infrastructure. A first engagement defines one useful role for the agent, the memory and tools it needs, the approval boundaries and an observable success criterion. For an approval workflow, that means the request types, the rules table, the approver list, the permissions and the record format are written down and owned by your team. Managed operations then include monitoring of misroutes, recurring evaluations, permission review and controlled changes to the rules, so the workflow stays accurate when people, policies and tools change.

Frequently asked questions

Can an AI agent approve requests itself? It can, technically, but for anything with financial, legal or customer impact it usually should not. A safer design lets the agent approve nothing and handle only the preparation, routing and recording. If your company ever allows automatic approval for trivial, reversible cases, write that as an explicit rule with an owner and review it regularly.

What happens when the agent is unsure who should approve? It sends the request to a named triage owner with its classification and the reason it was unsure. It should never guess or fall back to the most senior person. Each of these cases is also useful data: repeated uncertainty on one request type usually means a rule is missing.

How do we stop people from gaming the workflow? Take identity and role from the company directory, not from the request text, and treat claims inside the request as unverified. Keep separation of duties in the rules so that nobody approves their own request, and flag requests split into smaller pieces to stay under a limit. The record makes patterns like these visible during review.

How do we know the workflow is working? Choose an observable success criterion before launch, such as the share of requests routed to the right approver on the first attempt as judged in review, or the time requests wait before reaching a decision maker. Review misroutes and overrides on a regular schedule. For guidance on measuring without inflated claims, see how to measure AI workflow ROI.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.