Bretton’s agent harness makes our platform regulator-approved

September 3, 2026

Fourth in a series on running AI agents in production inside a financial institution. This piece is about the foundation layer beneath our agents: the harness that runs a long investigation without letting it drift from its primary purpose—passing an examiner’s test.

Inside the harness: how Bretton AI makes reliability a property of the system

Financial-services investigations are complex and high-stakes. A single case can span dozens of systems, hundreds of documents, and multiple entities, resolved through a long chain of decisions. Often, sources can conflict, tools can fail, or important facts surface with varying levels of detail. But the required checks still have to happen, every time, whatever else is going on in the case.

Our challenge comes from not just ensuring that our agents are reasoning well. It comes from making the whole investigation complete, grounded, consistent, and auditable, from intake to disposition. That is what our agent harness is built to do. It is the execution layer beneath every agent on the Bretton AI Platform, and its job is to hold a long investigation to a standard the model alone cannot guarantee.

Task accuracy is not case accuracy

Long horizon investigations compound small failures. As the first piece in this series noted, nine independent steps at 95 percent each succeed together only about 63 percent of the time. Good reasoning does not save you from that arithmetic.

In our first post of this series, we explored the "compounding error" problem with non-deterministic models

The harder problem is that most of these errors do not look like failures. Let’s say a tool times out. Often, this goes completely unnoticed, and as a result, a required check silently disappears. Maybe two agents calculate different totals for the same account—frontier models are still notoriously bad at simple math. Or perhaps a citation points to a source that was never actually opened.None of these errors are obvious. The final report can read as clean, complete, and persuasive while resting on a missed check or an unsupported number. This is why hallucinations can be so dangerous.

In financial services, this is not at all okay. Examiners expect predictable results, and as we mentioned in prior posts, predictive systems are far from predictable. The agent harness is built to keep this from happening. The work that actually happened, the evidence that was actually retrieved, and the parts that failed are all kept in the record, or prevented completely.

Keep related work together

Parallelism is useful, but fragmenting an investigation creates inconsistency. If five agents independently research the same company, they can resolve its identity differently, rely on different evidence, and reach conflicting conclusions. The more often related work is split apart, the more reconciliation has to happen afterward, and reconciliation is itself a place for errors to enter.

We found that fewer, larger investigators work better. One investigator owns an entity and does its related work in shared context. Research carries across steps. Identity is established once. That being said, we still often run into conflicts. When this happens, it kicks off our conflict resolution workflow.  When a conflict appears, it goes back to the investigator that holds the underlying evidence, not to a separate process trying to referee two accounts of the same fact. We split work when scale actually requires it, not on the assumption that more agents are inherently better.

Make required work explicit

A required compliance check should not vanish because a model forgot it, a tool failed, or the investigation took an unexpected turn. So required work is made explicit rather than left to memory. Each investigator carries a checklist of what has to be resolved for its part of the case. It is to keep required work visible while the investigation is happening, not discovered missing after the fact.

Before the agent can submit any completed work, it must verify that the entire checklist is complete. We use a technique called attention anchoring to ensure this happens correctly. If the checklist is completed, it is recorded as completed. If it genuinely does not apply, that is also recorded clearly. If it cannot be completed, that stays visible too. What the system does not permit is silent omission. This is how the harness transforms "don't omit this piece of evidence" from a line in a prompt into an operational constraint the case cannot skip.

Long-running agents need durable infrastructure

An investigation should behave more like a distributed system than a chat session. Sometimes workers restart, external systems time out, or stages complete partway. Some operations can be retried safely; others will duplicate data if they run twice. Treating a case like a single long conversation ignores all of that.

So cases run as durable workflows with explicit state, timeouts, retries, and defined failure semantics. Reliability here does not mean retrying everything. It means knowing exactly what can be repeated, what cannot, and how a failure is recorded when something does not complete cleanly. The difference matters most precisely when a case is large and something goes wrong halfway through.

Keep the evidence out of the prompt

Large cases quickly exceed what should sit in model context. So documents become searchable files, transactions become queryable data, and agents retrieve evidence as they need it. This keeps the working context focused while leaving the underlying case data durable and inspectable long after the run. The agent reasons over the evidence. The harness stores it.

Enforce, don't plead

Most reliability controls start life as prompt instructions: 

  • Always cite your sources.
  • Do not invent numbers.
  • Confirm this is the same person.
  • Never skip a required check. 

Each is a reasonable request, and each depends on the model remembering to honor it under pressure, across a long case, every time. For anything genuinely non-negotiable, that is not good enough. We try not to ask the model to remember it. We enforce it.

  • Numbers are deterministic. Transaction totals and other material figures are computed in a controlled way, and the narrative binds back to those canonical values rather than to whatever the model wrote down.
  • Citations are grounded. A source counts only if the harness knows the agent actually retrieved it. A search snippet or a failed request does not become a citation.
  • Identity is verified. A consequential finding needs a durable identifier connecting the evidence to the subject, not just a matching name.
  • Failures stay visible. A failed or incomplete check is recorded as exactly that. It does not quietly become "nothing found."

The pattern across all of it is simple: if we keep strengthening a prompt instruction, it probably wants to become a system constraint.

What we built

The harness gives agents freedom where judgment matters and takes control where correctness matters. The agent researches, interprets, resolves ambiguity, and writes. The harness keeps related work together, makes required work explicit, manages state, stores evidence, preserves calculations, verifies identity, and records what happens when something fails.

That separation is what helps this work. It lets us run genuinely complex investigations without making the workflow itself probabilistic. Judgment is allowed to be probabilistic, because judgment is where a model earns its place. Correctness is not.

What this means

A reliable financial-services agent should be able to show more than its conclusion. It should show what checks ran, what evidence was retrieved, which entity each finding belongs to, where the numbers came from, and what failed along the way. 

A plausible report is not enough. What an examiner, a model risk team, or your own second line actually needs is a durable record of how the agent reached its answer. We ensure that agent tracing and our audit log are treated as first class citizens, not nice-to-haves.

That is the standard the harness is designed around, and it is a large part of what separates an agent you can demo from one you can put into production and defend.

If you are building complex compliance or financial-operations workflows on agents and want that kind of record underneath them, we should talk.

Share this post
Copied!

Table of contents