AI Agent Approval Workflows: When to Automate vs. Require Human Approval

If we put everything behind an approval step, there’s really no point bringing in an AI agent at all. But going fully automatic frankly terrifies me.

That was Mr Saeki, who is driving the automation of invoice processing in the business planning department, speaking in a meeting room one Monday morning. I happened to be in the room myself, and that single remark captured the hesitation that so many companies run into when they bring in an AI agent.

The IT systems lead was anxious about the traceability of the logs, the accounting manager worried about misdirected sends and incorrect amounts, and the people on the ground were concerned that the pile of “awaiting confirmation” items would only grow. In the past, organisations couldn’t quite settle on an approval flow for their AI agent, and they tended to fall back on a binary choice: route everything through human approval, or fully automate only a narrow slice of work.

These days, however, some companies are taking a different tack with their AI workflow design. They sort work into risk grades based on factors such as the amount requested, the type of counterparty, the number of past exceptions and whether anything is sent externally; low-risk work runs automatically, high-risk work gets a double check, and the middle ground requires approval only when a threshold is exceeded. Even when you use a business-support platform such as Kanata, which lets you organise users, data and AI features on a per-project basis, defining your approval policy, approver roles and guardrails up front makes it far easier to design an operation that neither hobbles the AI agent nor hands it too much.

In this article, I’ll set out how to decide where the line falls between automatic execution and human approval, framed as automation levels keyed to business risk. The aim is an approval flow that doesn’t leave the team second-guessing every time, and that you can explain to auditors and to IT. That said, approval design alone won’t get incidents down to zero. Alongside log management, training and periodic review, let’s think through the dividing line that genuinely suits your own operations.

What to settle first when designing an AI agent approval flow

When you bring in a task-executing AI agent, the first muddle that tends to surface isn’t simply “what do we let the AI do”. It’s “before the AI acts, who can stop it, and under what conditions”.

With a rough draft or a meeting summary, a person can look at the output and fix it. A task-executing AI agent is a different beast. Sending an email, entering data into an internal system, raising a request, updating customer information, transcribing invoice data — the moment any of these is carried out, it becomes part of the business process.

In my work supporting AI adoption, I’ve come up against this point time and again. Technically, it can be automated. The APIs can be wired together. The on-screen operations can be automated too. And yet, at the very last step, the question lingers: “is it really alright for the AI to press the button?”

Press on with development while ducking that question, and it’ll grind to a halt later, in operation.

When you design an AI agent approval flow, you first need to separate out the following three things.

The range the AI may judge. For instance, classifying input according to existing rules, detecting missing documents, or converting things into a set format.
The range the AI may execute. This covers work that’s easy to undo or correct even if it goes wrong — drafting internal memos, saving drafts, raising approval requests, and the like.
The range where human approval must always be inserted. External sends, finalising amounts, changing contract terms, overwriting customer data, altering permissions — operations whose reach is large.

Implement with this left vague, and the team ends up unsure “just how far are we actually allowed to leave to the AI”. The upshot is that, even with an AI agent in place, every operation gets checked by a person, and the efficiency gains you were hoping for are hard to come by.

On the other hand, if you lean towards full automation from the outset simply “because we want to be more efficient”, then when a misdirected send or a faulty entry does occur, you’ll be unable to explain who decided what.Approval flow design isn’t a mechanism for stopping the AI. It’s a design for making clear which range you leave to the AI and which range a person remains accountable for.

Getting out of the “approve everything” versus “automate everything” binary

In discussions about business AI approval, two extreme positions tend to come up.

One holds that “because there’s risk, a person should approve everything”. The other holds that “if you’re going to bring in an AI agent, it’s pointless unless you make it as fully automatic as possible”.

There’s reason on both sides. For work where mistakes carry heavy consequences — invoicing, contracts, HR, customer-facing tasks — wanting to insert human approval is only natural. But if all a person is doing is performing the same sort of check over and over, the value of the AI agent is hard to realise.

What I often tell teams on the ground is: “don’t judge by the name of the task alone”.

For example, lump it all together as “invoice processing is risky, so it can’t be left to the AI” and you’ll scarcely move forward. Yet within that same invoice processing, the work of “renaming an invoice file according to a rule” and the work of “finalising the invoice amount and sending it to the counterparty” carry very different degrees of risk.

Even within the same customer-facing work, “drafting candidate FAQ answers” and “sending a reply email to a customer” call for different approval levels.

In other words, an approval flow needs to be designed not per task, but per operation.

For instance, breaking things down as follows tends to move the discussion along.

Operations that only read information
Operations that create a draft
Operations that save temporarily to an internal system
Operations that notify colleagues inside the organisation
Operations that send something externally
Operations that change amounts, contracts, permissions or customer data

Break operations down this way and a middle path becomes possible — neither “approve everything” nor “automate everything”. Low-risk operations run automatically; human approval goes in only for operations whose reach is large. This is the foundation of an AI agent approval flow.

When the discussion has stalled, I tend to write the business process out on a whiteboard. Then, one by one, I check: “is this just reading”, “does this rewrite something”, “does this go outside”. Abstract unease, once broken down into operations, turns into risk you can actually handle.

Five criteria for deciding the line between automatic execution and human approval

Decide the line between automatic execution and human approval by gut feel, and it becomes person-dependent. In one department it can run automatically, in another everything is checked by hand. One person trusts the AI; another sends it back every single time. When this sort of inconsistency creeps in, the AI agent struggles to settle in as a piece of business infrastructure.

To make an approval flow stable, you need to put the criteria down in writing.

Amount, volume and reach

The most readily understood criterion is amount or volume.

For expense settlement, invoice processing and ordering, for instance, you might design the approval level to rise as the amount grows. Small, routine items run automatically under the AI; once a certain amount is exceeded, a manager’s approval is required; and for higher amounts still, you add approval from a department head or a back-office function.

That said, judge by amount alone and things get missed. Even small sums, processed in large batches, have a wide reach. You need to look at the per-item amount, the number of items, the total, the number of customers affected, and so on, in combination.

When I supported one company, they too initially tried to set a threshold on “the amount per item” alone. In practice, though, there was work that executed a great many small updates in one go, and seen in terms of total impact it was a scale you couldn’t ignore. In an approval flow, it matters to look not just at the unit price but at the impact of the processing as a whole.

Whether there’s an external send or external system operation

For operations where information leaves the organisation, setting a high approval level is the basic rule.

If the AI merely saves a drafted email internally, the risk is limited. But sending it to a customer, registering it on a counterparty’s portal, or pushing it to an external advertising account — these operations have an effect on the outside world.

In this case, a realistic design limits what the AI agent can do to “getting everything ready up to the brink of sending”, with execution happening only after human approval.

At customer touchpoints in particular, the judgement involves not only “is the content correct” but “is this the right moment to send” and “does this phrasing risk damaging the relationship”. This is territory where a human, rather than the AI, ought to read the context.

Handling of personal and confidential information

For work that handles personal information, contract information, non-public information or a customer’s confidential information, you need to set the AI agent’s automation level with care.

Particular caution is warranted where the work involves not merely processing information but transcribing, sharing, sending or granting permissions on it. There’s a risk the AI sends to the wrong recipient, includes information it shouldn’t, or references data it isn’t meant to.

In this area, it’s important to set guardrails as rules: “if a particular data field is included, approval is always required”, “halt automatically on detecting sensitive information”, “check the masking state before sending”.

When using Kanata too, the premise for handling personal or confidential information is to mask it before input, work with it inside a project managed within the organisation, and have a person check any output that goes outside before it’s used. Before you leave anything to the AI, confirm whether the information is something you should be handing the AI in the first place. Not skipping this one step is the bedrock of business AI approval.

Reversibility

You should run a different approval flow for work that’s easily undone if it goes wrong than for work that isn’t.

Generating an internal memo or saving a draft, for example, can be corrected later. By contrast, sending to a customer, applying contract terms, finalising an invoice amount or changing account permissions are awkward to reverse. In some cases, they require customer follow-up or an audit response.

The harder an operation is to redo, the more it’s worth inserting human approval or a double check.

I often put it like this: “think in terms of whether you can roll it back”. Debate the AI’s accuracy in isolation and the conversation drifts into abstraction. But ask “can we roll this back if it goes wrong”, and both the business side and IT find it easier to judge.

The frequency of exceptions

AI agents suit work where the rules are clear and exceptions are few. Conversely, for work where the criteria are vague and which leans on a person’s experience, it’s safer not to lean too heavily on automatic execution from the outset.

For work with many exceptions — “this counterparty differs from the usual rule”, “only this customer has special terms”, “the practice changes for this period only” — there’s a chance the AI makes a faulty generalisation.

In this case, a design that leaves the AI to draft candidates and organise the points, with the final execution done by a person, fits well. The realistic approach is to raise the automation level once you’ve built up operational experience and the exception patterns have been sorted out.

With AI adoption, it’s tempting to automate a large piece of work wholesale from day one. In my experience, though, what suits best at the start is “a small process with few exceptions”. Entrust a little, watch the logs, and gradually widen the range you delegate. Simply keeping to that order makes the post-adoption confusion much easier to reduce.

Organising the approval flow by risk grade

Once you’ve teased out the criteria, the next step is to translate them into risk grades. A risk grade is the idea of classifying business operations by the size of their risk and setting approval rules for each.

Here, thinking in four levels makes things easier to organise.

AI agent risk grades and the thinking behind the approval flow
Risk grade	Examples of applicable work	The thinking behind the approval flow
Level 1: work that may run automatically	Tidying internal memos, converting to a set format, cleaning up file names, classifying existing data, and so on	Rather than approval each time, keep things in a state where logs are retained and can be checked afterwards
Level 2: work that may run automatically under conditions	Processing with a track record of the same task before, amounts below a set figure, or where the target is limited to inside the organisation	Route to human approval only when a threshold is exceeded
Level 3: work that requires human approval	Sending emails to customers, finalising invoice data, changing ad-delivery settings, HR-related notifications, and so on	The AI drafts candidates, and a person approves before execution
Level 4: work the AI agent should not be allowed to execute	Finalising end-of-cycle HR evaluations, judging significant contract terms, decisions carrying legal liability, management decisions themselves, and so on	Keep the AI to support such as organising the points or building comparison tables; a person handles the final judgement and execution

Level 1: work that may run automatically

Level 1 is work the AI agent may execute automatically.

For example, tidying internal memos, converting to a set format, cleaning up file names, drafting internal notifications, classifying existing data. These are operations that are easy to correct if they go wrong and whose external impact is limited.

At this level, rather than inserting human approval every time, it’s more practical to retain logs and keep things in a state you can check after the fact. Emphasise recording and monitoring rather than approval.

In my experience, make work even at this level subject to approval and the team tires of it in no time. Under an operation where you approve every file name and internal memo the AI has tidied, the AI agent stops looking like a handy mechanism and starts looking like a procedure-laden one.

Level 2: work that may run automatically under conditions

Level 2 is work that may run automatically, but only where certain conditions are met.

Conditions such as: there’s a track record of the same processing before, the amount is below a set figure, the target is limited to inside the organisation, the reference data is up to date. While the conditions hold, the AI executes; only when they’re not met does it go to human approval.

In this design, thresholds matter. You need to be clear about what tips something into approval — amount, count, delta, confidence, an exception flag, and so on.

This idea of “approval only when a threshold is exceeded” is important for bedding the system in on the ground. Rather than a person looking at everything, they look only at what warrants looking at. The value of an AI agent only emerges once you can narrow things down like this.

Level 3: work that requires human approval

Level 3 is work where the AI drafts candidates for execution and a person approves before it runs.

Sending emails to customers, updating contract-related documents, finalising invoice data, changing ad-delivery settings, HR-related notifications — operations whose reach is large.

At this level, it’s important to be clear about what the approver should check. Merely re-reading the AI’s output in full puts a heavy load on approval. Have the AI organise the delta, the rationale, the exceptions, the risk assessment and the reasons for its recommendation, so the approver can check only the information they need to make a decision.

For instance, when the AI agent raises an approval request, attaching the following information makes it easier to use in practice.

The operation it’s about to perform
The data it referenced
The delta from last time
Why it fell within the threshold
The risks anticipated
The items it would like the approver to check

Eliminating the state where an approver “doesn’t know what to look at” is the first step towards keeping an approval flow from becoming a hollow formality.

Level 4: work the AI agent should not be allowed to execute

Level 4 is work the AI agent should not be allowed to execute.

For example, finalising end-of-cycle HR evaluations, judging significant contract terms, decisions carrying legal liability, judgements that materially affect an individual’s rights, management decisions themselves.

In this area, the AI should be kept to a supporting role. It can be put to use organising the points, building comparison tables, surfacing risks, searching past cases and so on, but a person handles the final judgement and execution.

Widening the AI agent’s scope of use and having the AI execute everything are not the same thing. If anything, making clear the areas you won’t let it execute is what widens the areas you can comfortably leave to it.

When I support AI adoption, I sometimes draw up a “list of things not to leave to the AI”. At first glance it looks negative; in practice it’s the opposite. Precisely because the areas you won’t delegate are clear, it becomes easier to push automation forward in the areas you do.

Designing approver roles

Something easily overlooked in an approval flow is approver roles.

With a vague design in which “someone approves”, things tend to clog up once the operation gets going. Who does the approval request go to? What happens if the approver is away? What is the approver accountable for? Leave these undecided and the AI agent keeps stalling right before execution.

It helps to think of approver roles as split, at minimum, in the following way.

On-the-ground approver: Checks whether the substance of the work matches reality. For invoice processing, they check the transaction in question, the amount, the delivery status, what was agreed with the customer, and so on.
Business owner: Judges not only the correctness of the individual processing but whether it follows the rules, whether it should be treated as an exception, and whether the organisation can tolerate it.
IT systems / information security lead: Checks access rights, logs, data integrations, external sends, system permissions, and so on.
Audit / back-office function: Checks whether the operation is one you can explain after the fact. Logs of the approver, the rationale for the judgement, the send-back situation and so on become important.

On-the-ground approver

The on-the-ground approver checks whether the substance of the work matches reality.

For invoice processing, for example, they look at the transaction in question, the amount, the delivery status, what was agreed with the customer. Their role is to send things back when the AI’s processing is formally correct but out of step with the context on the ground.

On-the-ground approvers have a feel for the work. I don’t think that instinct should be taken lightly. However well the AI can read the rules, context such as “this counterparty is a touch unusual just this month” is something the people on the ground tend to hold.

Business owner

The business owner checks the soundness of the business process as a whole.

They judge not only the correctness of individual processing but whether it follows the rules, whether it should be handled as an exception, and whether the organisation can tolerate it. For mid-risk processing and above, separating the on-the-ground approver from the business owner helps the double check actually work.

The business owner’s role isn’t simply “the person who approves”. They’re also the person who improves the approval flow itself. Spotting processing that gets sent back often, revisiting the rules, adjusting the automation level. Bring this operational improvement into the scope of their responsibility too, and the AI agent grows over time.

IT systems / information security lead

The IT systems and information security lead check access rights, logs, data integrations, external sends, system permissions and the like.

Which systems the AI agent connects to, which data it references, which operations it can execute — these aren’t things the business function can judge on its own. Where external services or third-party APIs are involved in particular, technical approval is required.

Having spent time as an engineer on the development side myself, I feel this keenly. Even where the business side thinks “we’d like to automate roughly this much”, behind the scenes there’s a great deal to consider technically — permission design, audit logs, API limits, recovery in the event of a failure. IT isn’t the brake; it’s the designer that lets things run safely.

Audit / back-office function

Audit and back-office functions check whether the operation is one you can explain after the fact.

Who approved it, on what basis the AI built its candidate, how often things were sent back. Without logs like these, you can’t trace the cause when a problem arises.

When designing approver roles, the important thing is to think not “have someone senior approve it” but “have the person who holds the responsibility and the information the decision needs do the approving”.

Place guardrails before, during and after execution

Mention AI agent guardrails and people tend to picture only the pre-execution approval. In practice, though, you need guardrails in three places: before execution, during execution and after execution.

This way of thinking sits well with the international debate on AI governance. For instance, NIST’s AI Risk Management Framework sets out an approach to managing AI risk through the functions “Govern”, “Map”, “Measure” and “Manage”. The EU AI Act, for its part, underscores the importance of human oversight for high-risk AI systems.

Pre-execution guardrails

Pre-execution guardrails are a mechanism for detecting unsuitable content in the AI’s proposed action before it’s shown to a person.

For instance, conditions such as: a mandatory field is missing, the amount falls outside the usual range, the recipient is external, personal information is included, the reference data is stale.

Catch it here and you spare the approver an unnecessary check. It’s important to build a state in which the AI agent itself can judge “I can’t execute under these conditions” or “this needs approval”.

I sometimes call this stage “designing self-restraint into the AI”. The AI doesn’t, of course, possess self-restraint in any real sense. But by making the conditions for execution and the conditions for halting explicit, you can build a mechanism that stops in dangerous situations.

During-execution guardrails

During-execution guardrails are a mechanism that detects an anomaly while the AI agent is partway through processing and halts.

For example, it’s about to process more items than planned, it’s about to notify the same customer several times, or it’s about to rewrite a system field that’s out of the ordinary.

In human work too, if something feels off partway through, we stop. The AI agent likewise needs to hold conditions under which it halts when something’s amiss.

With task-executing AI agents in particular, it can happen that “there was no problem before execution, but partway through it meets data it didn’t anticipate”. That’s precisely why pre-start approval alone isn’t enough. Being able to stop partway is an important guardrail in its own right.

Post-execution guardrails

Post-execution guardrails are a mechanism for recording the result so it can be checked afterwards.

Which work, when, by which AI agent, on the basis of which data, under whose approval, was executed. Did the result succeed, get sent back, or get corrected? Retaining these as logs makes operational improvement possible.

Guardrails aren’t merely something that constrains the AI’s behaviour. If anything, they’re the operating environment that lets you fold an AI agent into your operations with confidence.

I don’t think of an AI agent’s logs as merely “a record for assigning blame”. They’re needed for audits and incident response, of course. But more than that, logs are raw material for improvement. Where did it stop? Where did a person make a correction? Which threshold was too strict? Look at these and the next design comes into view.

How to think about approval flow design when using Kanata

There are several ways to build an AI agent foundation — bespoke development, making use of existing SaaS, integration with RPA, embedding it in an internal portal. Among these, when you use Kanata, it’s important to think of the approval flow not as a standalone feature but as one piece with your business rules, prompts, training data, permissions and logs.

For instance, if you leave invoice processing to an AI agent, what you need isn’t just an “approve button”. You need the rules for invoice processing, the exception conditions, the internal rules to reference, the approver roles, the summary shown when an approval request is raised, and the post-execution logs.

With Kanata, you can organise users, data and AI features per project and create an environment where you can collaborate safely on a per-task basis. You can also combine features such as AI chat, AI summarisation and e-learning, shaping the knowledge and prompts the work needs into a form the team can readily reuse.

If you’re designing business AI approval, a flow along the following lines is one to consider.

Organise the target work on a per-project basis. Work that handles different information and involves different stakeholders — sales, accounting, HR, customer success — is easier to manage if you split it into separate projects.
Register the business rules and reference materials within the project. This is to make clear what the AI agent bases its judgements on. Rather than pasting the same materials in every time, getting them in order as knowledge the team uses helps keep the AI’s output stable too.
Set, for the AI chat and the task-executing agent, the items to check before approval, the range it may execute, the prohibitions, and the conditions for halting when an exception arises.
As you run the approval flow, revisit the reasons for send-backs and the handling of exceptions. Rather than building a perfect approval design from the start, it’s realistic to grow it to fit your own operations while watching the logs.

Kanata suits companies that would rather operate while organising their business rules, users, data and prompts on a per-project basis, than use AI as a one-off handy tool. The same goes for an AI agent’s approval flow. Translating it into rules the organisation can reuse, rather than relying on individual judgement, is what helps it bed in on the ground.

Operational points for keeping an approval flow from becoming a hollow formality

An approval flow doesn’t work simply because you’ve built it. If anything, when the design is too heavy, the people on the ground start hunting for ways around it.

It’s a nuisance needing approval every time, so they get on with it by hand without using the AI
The approver presses the approve button without looking at the content
No reasons for send-backs are retained, so the same mistake gets repeated

Once things reach this state, the approval flow ceases to be a guardrail and becomes a formal procedure.

To prevent it becoming a hollow formality, three things matter.

Narrow down what the approver looks at

Make the approver check everything and the load gets high. Have the AI agent gather the changes, the risk assessment, the source, the exception conditions and the reasons for the recommendation, so the approver can look only at the points the decision needs.

When there are too many items to check on the approval screen, in the end nobody reads them.

I sometimes design admin and approval screens in product development work. What I always keep in mind there is the premise that “people make decisions while busy”. You mustn’t expect them to read everything carefully in ideal conditions. You need to narrow down the information worth seeing so they can decide even when pressed.

Build up the reasons for send-backs

A send-back isn’t merely a failure. It’s important data for improving the approval flow.

Under which conditions do send-backs happen most? Is the AI’s judgement off? Are the business rules vague? Do judgements diverge between approvers? Building up the reasons for send-backs lets you revisit your thresholds and policies.

If the same reason keeps coming back, for instance, it may be that the instructions to the AI or the reference data are lacking. If judgements diverge by approver, perhaps the business rules themselves are vague.

Treat send-backs not as something to censure but as raw material for improvement. This stance is indispensable in operating an AI agent.

Review the automation level periodically

It’s perfectly fine to insert plenty of human approval at first. What matters is reviewing it once you’re up and running.

Processing that’s had next to no send-backs over a set period might be moved to conditional automatic execution. Conversely, processing that needs a lot of correction after automatic execution may need its approval level raised.

An AI agent’s approval flow isn’t done once you’ve built it. As your business rules, the people involved, your systems and your customer conditions change, the approval design changes too.

I regard AI adoption not as “a project to put a system in” but as “a project to grow the business”. An AI agent, likewise, fares better when you grow its accuracy and rules while operating it, rather than demanding the finished article from the start.

Common pitfalls

Here I’ll set out the failures that tend to crop up in AI agent approval flows.

Too many approval points

Put approval on every operation and the work on the ground grinds to a halt. The AI agent drafts something, a person checks it, another person approves it, and then an administrator checks it again. This can end up slower than doing it by hand.

More approval doesn’t make things safer. It works precisely because you narrow it to the points that matter.

From what I’ve seen, the more cautious the company, the more prone it is to this failure. Caution is important, of course. But try to absorb every risk through approval and the approvers become the bottleneck. Manage low-risk operations through logs and have a person look only at the important operations. That separation is what’s needed.

Approvers who don’t understand their responsibility

There are also cases where the person pressing the approve button doesn’t understand “what am I responsible for”.

Are they looking at the soundness of the content, the amount, the customer impact, the security? When the scope of the check is vague, approval becomes a formality.

A “just get the manager to approve it” design is dangerous, for all its apparent simplicity. The manager doesn’t necessarily grasp every detail of the work. Approvers should be decided not by job title but by whether they hold the information the decision needs.

The AI’s basis for judgement isn’t visible

Even if the AI agent judges that “no approval is needed”, if the reason isn’t visible, people can’t leave things to it with any confidence.

Which policy did it match, which threshold did it fall below, which data did it reference? Displaying the basis for the judgement makes it easier for approvers and the audit function to explain it.

An AI’s judgement loses trust the moment it looks like a black box. Conversely, with the rationale visible, you can improve even when there’s the odd mistake. Retaining “why it judged as it did” is fundamental to supporting the reliability of AI agent operation.

No allowance for exception handling

Build an approval flow on the premise of routine processing alone, and the moment an exception arises, the people on the ground come to a halt.

Special terms by counterparty, urgent requests, an absent colleague, system failures, missing data — exceptions do happen. You need to decide, for when an exception arises, whether the AI halts and who it escalates to.

In business-design meetings, I always ask “what are the exceptions”. At first the reply is sometimes “there are hardly any”. But ask the people doing the work and several exceptions usually emerge. An AI agent’s approval flow needs to be designed to take in not just the clean, standard work but the messy exceptions too.

An AI agent approval flow design checklist

When designing an approval flow for an AI agent at your own company, check the following points.

Breaking the work down

Have you broken the target work down to the level of individual operations?
Have you separated the operations where the AI reads, creates, saves, sends and updates?
Have you distinguished reversible operations from those that are hard to reverse?

Risk grades

Are you using amount, volume and reach as your criteria?
Are you treating external sends and external system operations separately?
Have you decided the conditions for halting where personal or confidential information is involved?
Are you treating work with many exceptions as high-risk?

Thresholds

Have you put in writing the conditions under which something is routed to approval?
Can you explain the basis for the thresholds?
Do you have an operation that reviews the thresholds periodically?

Approver roles

Have you decided who approves what?
Is there a deputy rule for when an approver is away?
Have you defined the work that requires a double check?
Have you narrowed down the items the approver should look at?

Guardrails

Are there check conditions before execution?
Are there conditions to detect an anomaly and halt during execution?
Are logs retained after execution?
Can you build up the reasons for send-backs?

Operational improvement

Are you watching the number of items awaiting approval?
Are you watching the number of send-backs and their reasons?
Are you periodically reviewing the range that may run automatically?
Are the ground, IT and back-office functions holding improvement meetings?

This checklist isn’t merely a tick-sheet. It’s a set of design items for turning an AI agent from a “handy automation tool” into an “explainable business foundation”.

In closing: an approval flow isn’t a mechanism for stopping the AI agent, it’s a design for how you delegate

When you bring in a task-executing AI agent, what matters most isn’t only “how far can we automate”. It’s deciding, at the same time, “from where does a person hold the responsibility”.

Put everything behind approval and there is, admittedly, a sense of reassurance. But the “awaiting confirmation” pile grows and the AI agent’s value is hard to realise. Lean too far towards full automation, on the other hand, and the risks loom large — misdirected sends, faulty entries, an absence of accountability.

What’s needed is to vary the automation level according to business risk.

Low-risk operations run automatically. Mid-risk operations are routed to human approval once a threshold is exceeded. High-risk operations have clear approver roles and, where necessary, a double check. And you decide in advance the areas you won’t let the AI execute.

Only once you can draw this line does an AI agent become a business foundation you can use on the ground with confidence.

That said, an approval flow isn’t done once you’ve built it. As your business rules, organisational structure, the data you handle and your customer conditions change, the right approval design changes too. It’s important to watch the logs, analyse the reasons for send-backs, and adjust the automation level little by little.

I don’t regard designing an AI agent’s approval flow as a debate about whether or not to trust the AI. It’s business design in itself — deciding which work, under which conditions, and under whose responsibility, you delegate.

Look at technology alone and what an AI agent can do will only keep growing. But what truly matters on the ground in a company isn’t carrying out everything that’s “possible”. It’s designing the way of delegating that’s just right for your own organisation, with an eye on business outcomes, on-the-ground adoption, operational load, cost-effectiveness and risk.

Q&A

Which work should we build an AI agent approval flow from first?

It’s realistic to design first from work that has few exceptions and that’s easy to correct if it goes wrong. Tidying internal memos, converting to a set format, drafting, internal notifications and the like make good candidates. Start straight away with high-risk work such as contracts, invoicing or HR evaluation, and the approval design gets heavy and adoption on the ground becomes difficult.

Who should decide the line between automatic execution and human approval?

Best to avoid deciding it by the business function alone, or by IT alone. It’s preferable to have the on-the-ground staff who know the work, the business owner who holds the responsibility, the IT lead who watches systems, permissions and logs, and — where necessary — audit or back-office functions take part in the decision. An approval flow bears on both business design and risk management.

Does having more approvers make things safer?

Not necessarily. With too many approvers, the “awaiting confirmation” pile grows, and approval tends to become a formality in which nobody looks at the content properly. What matters isn’t increasing the number of approvers but making clear which risk each one checks. A double check can be effective for high-risk work, but treat low-risk work the same way and the operational load gets high.

How much of an AI agent’s basis for judgement should we retain?

At minimum, it’s preferable to retain the execution date and time, the target work, the referenced data, the rules used in the judgement, the reason it fell within the threshold, the approver, and the result of execution. Recording everything in fine detail makes the operation heavy, so adjust the items recorded according to business risk. It’s important to retain them in a form usable not only for audits and incident response but also for improving the approval flow.

How can Kanata be used in approval flow design?

Kanata suits the purpose of organising users, data and AI features on a per-project basis and making business rules and prompts easy for a team to reuse. When designing an approval flow, splitting projects by target work, organising reference materials and decision rules, and making clear what the AI bases its output on all help with operation. That said, the requirements for approval permissions and log retention differ from company to company, so you need to check consistency with your own security policy and existing systems.