Agentic Compliance: An Engineering Approach

In most enterprises, compliance checks happen after the transaction has already completed. The controls are tested afterwards through sampling, periodic reviews and batch reports. That model worked when products changed slowly and volumes were manageable. Digital platforms now release changes weekly, process transactions in milliseconds and operate across several jurisdictions at once. A control that is evaluated a month later can describe what happened, but it cannot prevent anything.

Agentic AI offers a way to close this gap. Agents can interpret an objective, monitor activity as it happens and take action within limits set in advance, such as flagging a suspicious transaction, escalating a high-risk case or adjusting a control when a regulatory threshold is met. My view is that the technology is capable enough to be useful now, and that the main risk lies in how organisations adopt it. Teams that add an agent to an existing compliance process will see modest gains. Teams that treat compliance as a system to be designed, with architecture, interfaces, tests and named owners, will see considerably more. The rest of this article sets out what I think that involves.

Apply compliance at the point of decision

The most mature examples are in payments. Card networks now score transactions for fraud risk within milliseconds, using contextual signals before a payment is authorised. Comparable real-time scoring exists for account-to-account payments, where each transaction is approved, declined or flagged on live data. In both cases the fraud checks, sanctions and risk rules sit inside the transaction flow and are applied while the decision is being made.

For each compliance obligation, the useful question is where in the workflow the decision is made and whether the control can be evaluated at that moment. A payment can be screened before release, a customer can be verified before an account is opened, and a change to a limit can be checked against policy before it takes effect.

I recommend starting with an inventory of decision points and not an inventory of policies. List the places where the organisation approves, declines, escalates or changes something, and map the obligations that apply to each. This gives engineering teams a backlog they can work through, and it shows which obligations are candidates for real-time enforcement.

Keep rules deterministic and use agents for judgement

A common mistake is to give the whole compliance problem to a language model. Regulatory thresholds, sanctions list matches and limit checks have exact answers. They should be implemented as deterministic code that can be tested, versioned and reviewed. Agents are better suited to work that involves interpretation: reading a regulatory update, judging whether a pattern of activity is unusual in context, drafting the rationale for an escalation, etc.

The architecture I would recommend has three parts. A deterministic policy layer enforces the hard rules. An agent layer handles interpretation, prioritisation and case preparation within limits that the policy layer defines. A human layer takes decisions that involve ambiguity or material consequence. An agent can be given wide latitude in how it investigates and narrow scope in what it is allowed to do. The guardrails should be enforced in code, through the permissions and interfaces the agent can reach, and not only through instructions in a prompt.

This also makes conversations with regulators easier. A system in which the binding rules are explicit and the agent’s authority is bounded is simpler to defend than one whose behaviour depends on how a model reads a prompt on a given day.

Explainability and audit trails have to be produced at decision time

Reference architectures for agents that handle anti-money-laundering and know-your-customer work place explainability and traceability in the core design. Explanations reconstructed after the fact from logs are inferences about what probably happened. Explanations recorded at the time of the decision are evidence, and auditors and regulators treat them differently.

For each agent action, the record should include the objective the agent was working towards, the data it retrieved, the rules and policies it applied, the alternatives it considered, the action it took, and the identity and version of the agent and model involved. The records should be stored so that compliance, internal audit and regulators can query them without engineering support.

Agents act on behalf of the institution, so they need their own identities, policy-based access and verifiable history of ownership for the data and instructions they act on. When these safeguards are built into the platform, product teams inherit them and do not need to re-implement them. This is how regulation can become a practical enabler at the system level than a constraint.

Define levels of autonomy and design the escalation path

Agents can handle routine work and pass complex and sensitive cases to humans. The design effort is in deciding what counts as routine, and I suggest defining explicit autonomy levels for each use case. At the lowest level, the agent observes and recommends. At the next, it acts on low-risk cases and reports what it did. At the highest, it acts on a wider class of cases, with sampled human review. Each use case should start at the lowest level and move up only when measured performance supports the change.

Escalation needs as much attention as the automation. If agents remove the routine work, the people who remain receive a concentrated stream of difficult decisions. Their capacity, tooling and authority need to be planned before the agents go live. An escalation that arrives with a clear summary, the supporting evidence and a proposed action can be resolved quickly. An escalation that arrives as a raw alert adds to the burden the agent was meant to reduce.

Measurement should cover false positives, missed cases, time to decision, the quality of escalations and the rate at which humans override the agent. Evaluation suites built from historical cases, including known edge cases and past regulatory findings, should run whenever a model, prompt or policy changes, in the same way that regression tests run when code changes.

Multi-agent designs work best when they mirror the operating model

Compliance work divides naturally into specialisations, and a multi-agent design can follow that division. One agent scans for regulatory change, a second scores risk, a third maps obligations to controls and a fourth carries out remediation. A coordinator handles delegation, conflict resolution, fallback and prioritisation. I think this is a sound pattern, provided that each agent has a narrow scope, a defined interface and its own evaluation.

A three-layer framing helps to assign responsibilities. An intent and orchestration layer initiates a compliance check. A control layer scans for and flags changes in regulatory requirements. A settlement layer validates that the check was completed and the outcome recorded. The separation matters because the agent that initiates a check should not be the one that validates it. Compliance functions already apply this principle of independent verification to people, and it carries over directly to agents.

For organisations that operate across jurisdictions, federated coordination allows local agents to apply local rules while sharing regulatory intelligence over secure protocols. Data sovereignty is maintained because agents exchange findings and not raw customer data. Teams should design for this from the start, since adding data residency to a centralised agent platform later tends to be expensive.

What to do next

Leadership should assign joint ownership of agentic compliance to the compliance and engineering functions, fund the shared platform, agree a risk appetite for each level of autonomy and involve regulators early. Engineering teams should begin with the decision-point inventory, separate deterministic rules from agent judgement, record explanations at decision time, start each use case at the lowest autonomy level and build the evaluation suite before extending what the agent may do.

Regulation will continue to change, and transaction volumes and speeds will continue to rise, so periodic and manual review will cover less and less of the activity it is meant to control. Organisations that build compliance into their architecture now will be able to show regulators how each decision was made, and they will find it easier to enter new markets and launch new products.