Agentic AI, meaning systems that don't just suggest but actually act, is starting to find its place in the conversation. Impressive demos make the rounds. Research papers land on the topic. A few deployments are beginning to surface publicly.

In a regulated sector like banking, the question isn't only whether it works technically. It's whether you can govern it. And to govern something, you first have to define it.

This paper offers that definition, as a series of questions. If a team can't answer them clearly before deployment, they'll answer them under pressure, after an incident. Not the best moment.

So far, AI in banking has mostly been about recommendation. A model suggests, a human validates. The trace is simple. You know who clicked, when, and why. Auditors can follow the thread.

An autonomous agent shifts that logic. It can chain multiple actions on its own. Read a file, check information, send an email, update a system, generate a document. All without a human between each step.

That's not a problem in itself. Many of these actions are mundane and benefit from automation. The real matter is that the trace no longer separates the mundane from the sensitive. Everything looks like a machine action. And when you later need to explain why a particular action was taken in a particular situation, the answer isn't easy to build.

Before writing code, you need to write a scope. Which actions are authorised. Which data is accessible. Which recipients are legitimate.

Sounds obvious put that way. In practice, the temptation is to ship something that works and tighten things up later. That's understandable. But the longer you wait, the harder it gets to narrow the scope without breaking what's already running.

The better reflex is the opposite. Start from the narrowest possible scope. Open things up case by case, with a reason attached to each opening. That discipline costs a little at the start. It saves a lot in maintenance.

Most systems record actions. An agent sent this email at this time. That's useful, but it's not enough.

To audit properly, you also need to record the decision. Why this action rather than another. Which data it drew on. Which rule authorised it. Without those three pieces, an auditor has the video but not the sound.

This takes design effort. Classic systems aren't built for it. Traceability rarely grafts on well after the fact. It's a property that has to be designed in from the start.

Compliance has traditionally been mostly ex-post. Let things run, check afterwards. That works fine when decisions are rare and made by humans.

With an agent capable of making many decisions very quickly, that model hits its limit. Nobody can review every decision in real time. And if you wait for an incident to look, it's too late.

The instinct is to want a human in the loop at every step. But you're back where you started. If a human has to validate everything, the agent serves no purpose.

So the right question isn't where to place the human, but where to place the rules. Ex-ante control means defining what's allowed upfront, and letting the system technically block the rest. The human keeps their place where it matters: final sign-off on actions that commit the institution, review of edge cases, arbitration of exceptions.

An agent that doesn't behave as expected can happen. The underlying model evolves. Context shifts. An edge case surfaces.

So you need to plan the exit from the start. Can you stop the agent cleanly, without breaking what it's already set in motion. Can you roll back recent actions, where it's technically possible. Can you explain, with solid material, what happened and why.

These aren't details. They shape what you can say to a regulator, a client, or senior leadership the day something goes wrong. Answering them after the incident means answering under the worst possible conditions.

Three simple principles, that follow from what precedes.

Start small. One use case, clearly defined, with a business team that owns it. The projects that fail are often the ones launched too broadly, too early.

Separate explicitly what's automatic from what isn't. Some actions can go through without validation. Others can't. The line must be written down, not implicit, and enforced by the system itself.

Design the evidence at the same time as the action. Every sensitive action carries an usable trace of the decision. It doesn't graft on well afterwards. It has to be baked in from the first lines of code.

Agentic AI isn't a technology problem. The technology works, often better than we imagined a year ago.

The real subject is governance. What you authorise, how you control it, how you prove it. These questions come before the first deployment, not after.

The organisations that will do well aren't the ones with the most impressive agents. They're the ones that took the time to frame what they were going to allow, and what they wanted to be able to prove. That work isn't glamorous. It's what separates a technology you live with from a technology you actually own.