How do you design an AI agent architecture for a regulated business?

Start from the controls, not the model. A regulated business needs an architecture where agents propose actions and a separate layer decides whether each may happen, using roles, limits and evidence held outside any model. Every fact carries its source, every verdict is recorded, and irreversible actions wait for a person. The model is the most replaceable part.

What layers does the architecture need?

Six layers, each with a clear owner.

The governing layer sits between agents and systems of record. Nothing an agent does reaches a system without passing it.

What principles should shape the design?

Separate proposing from deciding. The model suggests what to do next; the governing layer decides whether it may. A model that is both is marking its own homework.

Design roles, not prompts. A role states what the agent is for and which capabilities it holds. Prompts change often; roles should not. The case is made in why roles beat prompts as the basis for agent design.

Grant authority per capability. "The agent" is never one permission. Looking up an account, drafting a letter and issuing a refund each get their own depth.

Design tools as business actions. One tool per action with narrow parameters, rather than general access to a system. Guidance is in how to design tools for AI agents.

Sort actions by reversibility. Reversible work can run within bounds. Irreversible work waits for a person or is withheld entirely.

Record verdicts, not just events. Logs show what happened. A regulated business also needs to show why it was allowed and which bound decided.

How do you get from principles to a working design?

1. List the processes agents will touch and, for each, the capabilities involved.
2. Mark each capability's reversibility and the harm if it goes wrong.
3. Name an accountable owner for each process, matching how you already assign accountability for people.
4. Map each capability to its tools, sources and systems; the agent integration design template is built for this.
5. Decide where the governing layer runs and confirm it is in the path of every action.
6. Define how held actions reach approvers and what they see.
7. Plan certification on your own cases and the renewal cycle.
8. Define the record: what each verdict contains and who can read it.

What does this look like in practice?

Take a payments firm designing agents for merchant support. It identifies three processes: answering merchant questions, investigating failed settlements, and adjusting merchant fees. Answering is reversible and low harm. Investigating is read-heavy. Adjusting fees changes what merchants are charged.

The design gives each its own agent and role. The fee agent holds a draft capability at depth 2 and an apply capability that requires certification before it reaches depth 3, with the firm's own limit capping any single adjustment. Settlement data reaches the investigation agent stamped with its source, and anything a merchant asserts by email is marked external. Reversing a settled payment is withheld for every agent. The head of merchant operations owns all three roles; the risk function owns the limits.

What will regulators and auditors look for?

Whatever the market, supervisors tend to ask the same things: who is accountable, what the system may do, how you know it works, how a person can intervene, and what the record shows. In banking, model risk is supervised in most markets. Where you operate across borders, rules differ by country; Singapore's approach, for example, is covered in how AI agents are regulated in Singapore. An architecture that answers those five questions from its own records is ready for most of them.

Deployment practice, from pilot to scale, is covered in how to deploy AI agents in a regulated business. The governing layer itself is described in the governed agentic operating system guide.