Before giving an AI agent a task, define its authority

An AI agent is reviewing your supplier list. It gathers contract evidence and suggests that two supplier records are the same company. The names are close. The addresses overlap. The recommendation looks perfectly sensible.

Click approve, and you may have just merged two separate legal entities. Your spend reports change. A future audit gets harder. Nothing about the recommendation looked wrong.

The useful question isn’t how many steps the agent can complete on its own. It’s which steps you’re prepared to hand over, on what evidence and under whose authority. Reading a record, recommending a change, approving it and making it are four different jobs. They deserve four different answers.

Write the boundary in plain business language

Start with a task you could explain to a new colleague: find possible duplicate suppliers and prepare the evidence for a data steward. Then say which records the agent may look at, what a recommendation must include and who is allowed to approve a merge. Leave everything else out, even when a technical integration would make it easy to reach.

OWASP lists excessive functionality, permissions and autonomy as the roots of what it calls excessive agency, and recommends limiting what an agent can do and enforcing authorisation outside the model. In business terms: a persuasive explanation must never buy the agent extra permissions.

Name the stopping conditions too. Conflicting identifiers, missing evidence or an entity type the agent hasn’t seen before should all send the case to a person. Let the agent say “I couldn’t resolve this”. Demand a finished answer every time and you’ll get the appearance of certainty instead.

Make approval a real decision

An approve button is not a control. The reviewer needs to see the proposed change, the source records, why the agent recommended it and where the affected data is used downstream. Keep the differences between records visible. A good summary saves clicks. It shouldn’t hide the evidence someone would need to disagree.

Measure how long review takes while you evaluate. If checking a recommendation takes longer than doing the investigation by hand, the agent may still earn a place for specialist cases, but the business case should say so. Track why reviewers reject recommendations, not just how often they approve. A high approval rate can mean a reliable agent. It can also mean a reviewer with no time.

Keep preparing a recommendation and accepting its consequences as separate responsibilities. The person approving needs the authority, the context and a practical way to decline, amend or escalate. A reviewer without time or context is a ceremony, not a control.

Keep the evidence with the decision

Store the recommendation, the version of the sources it used, the reviewer’s decision and their reason together. After you change the model or the workflow, you should still be able to explain what produced an earlier recommendation. That doesn’t mean keeping everything forever: retention should follow your stated purpose and obligations.

NIST’s generative AI profile treats risk across the whole AI lifecycle. Our reading is practical: evaluate the full loop of recommendation and review, including the people, the source data and the model, rather than the model on its own.

Widen the remit only after watching real work

Start narrow. Compare the agent’s recommendations with what qualified reviewers decided, and include the awkward cases on purpose. A wider remit brings different records, permissions and consequences, so evidence from an easy task shouldn’t become blanket approval for a harder one.

In Akashic, AI agents are in preview. Pipeline agents help with pipeline work; matching agents propose entity matches for stewards to approve. Neither approves anything on its own or writes back into your source systems. A person decides.