Second in a series on running AI agents in production inside a financial institution. This piece tells our architecture story: how we moved from isolated, chained workflows to agentic investigation across three generations, and what each move taught us.
Three generations of building agents for financial services, and why the wins came from architecture
Building AI agents for financial services is unforgiving. The work lives inside regulated processes, the accuracy bar is high, and the underlying investigations do not stay simple for long. Early on, most of the problems were bounded enough to solve with chained prompt calls, heavy context injection, and deterministic orchestration around the model. Our focus was automating simple L1 investigations. That was the right architecture for the product we had then.
As the product proved useful, the work changed. We were asked to run deeper investigations, cover more edge cases, and produce outputs that did more than consolidate information. The system increasingly had to resolve messy entity identity, follow evidence across documents and external sources, connect related facts, take first-pass judgments, explain its uncertainty, and produce work that could survive downstream review.
That changed the product itself. Our architecture moved through three generations, internally named: Legacy Workflows, Agent V1, and Agents V2. Every generation described here ran in production inside financial institutions, carrying real cases under real controls. The important shift was architectural, supported by improved AI technology. Each move took a different kind of complexity out of code and put it in the right layer of the system.
To summarize, Legacy Workflows encoded the investigation in software, Agent V1 gave the model much more freedom inside that software, and Agents V2 redesigned the platform around agentic investigation itself.
Generation one: Legacy Workflows
In this generation, a case moved through a predefined sequence. The application decided which step ran, assembled the context, called a model with a purpose-built prompt, persisted the output, and moved to the next stage. The model answered a specific question. The application ran the investigation.
This structure created real value because it made messy work repeatable. It could take fragmented case inputs, customer documents, and entity data, move them through a defined sequence, enrich the subject, identify affiliates, run structured assessments, and generate a useful first-pass report. In screening, it turned structured alert inputs into a consistent evaluation of a flagged entity. In due diligence, it turned scattered inputs into a case file that was far easier to review. Much of the early product strength came from that: less manual coordination, the same checks applied every time, and document-heavy review made more consistent.
But the architecture eventually reached a ceiling of capability. Over time the system grew into a large workflow with many activities across entity creation, enrichment, document handling, affiliate discovery, research, assessment, and report generation. Adding a feature or use case was rarely just a prompt change. It usually meant adding an activity, deciding where it belonged, wiring dependencies, updating persistence, exposing the result in the product, and threading customer-specific behavior through code and large configuration objects. That made the system slow to extend and brittle to change. More fundamentally, it assumed the investigation path could mostly be designed in advance. That assumption eventually proved false as we expanded to new use cases.
Generation two: Agent V1
Agent V1 changed the role of the model inside the product. Instead of only answering predetermined questions, the system could give an investigator an objective, instructions, tools, and room to work across multiple turns. An agent could search, inspect results, open documents, compare sources, refine a hypothesis, and decide what to do next. This was the point where the product moved from consolidating information to taking first passes at the investigation itself, following evidence dynamically and handling cases that could not be fully decomposed in advance.
V1 also exposed the limits of keeping agents inside an architecture designed for chained prompt calls. Four problems stood out.
Fragmentation. Different subagents did good work on different slices of a case without sharing one coherent understanding of the subject, the evidence, or the open questions. You could end up with individually plausible outputs that did not cohere as a case.
Context handoff. As investigations got deeper, context had to be summarized and passed forward between stages. That works for bounded tasks and turns fragile when later work depends on details that do not survive compression: why a source was trusted, what remained unresolved, what evidence was discarded, which lead was a dead end.
Where logic lived. A V1 skill could hold methodology, domain doctrine, customer-specific rules, tool instructions, formatting, and runtime behavior all at once. That made skills powerful, but it meant shared intelligence kept getting embedded inside customer-scoped artifacts.
Enforcement. When something mattered, the instinct was to make the prompt more explicit: check identity, ground every claim, do not finish without covering required items. It helped, and it exposed the limitation. A stronger instruction is still just an instruction.
V1 proved the system could do real investigative work. It also made clear that the surrounding architecture had to change.
Generation three: Agents V2
V2 is a deeper redesign than "V1 with better prompts." It changes the unit of authorship, the unit of investigation, and the unit of evidence.
Authorship moved from prompts to a compiled configuration. An agent could not keep being written as one large customer-scoped instruction blob. Builder decomposes a workflow into the layers that actually need to exist at runtime: doctrine for global invariants (grounding, identity before attribution, treating gaps as gaps), skills for reusable technique, instructions for the customer-specific workflow, and knowledge for governed reference data. The running investigator prompt becomes a compiled artifact synthesized from those layers, versioned and frozen before runtime, so the system executes a specific built configuration rather than improvising one per case. That makes provenance explicit, lets shared improvements propagate instead of being rewritten per customer, and reduces drift. Instruction structure turned out to be product design, not prompt design. Builder, the part of the Bretton AI platform that allows customers to build agents themselves, gets its own piece next in this series.
The unit of investigation got larger. V1 inherited a one-skill, one-subagent shape. V2 groups a primary entity's work into a small number of composite investigators, with affiliates and counterparties each owned by one investigator that holds all the related work. This was driven by experiment, not taste: grouped investigators produced more coherent findings and fewer contradictions than architectures that split related work too aggressively. If several agents research the same company independently, they resolve identity differently and reach conflicting conclusions. If one investigator owns the related work, research carries across steps, identity is established once, and conflicts return to the investigator that already holds the evidence. Coherence is an architectural property. The harness that runs these investigators gets its own piece later in this series.
Identity became a first-class investigator. Extraction and entity resolution used to look like setup work outside the main investigation. In V2, extraction runs first, establishes the entity roster, and determines which downstream investigators should even exist. In financial crime and adjacent work, knowing who the case is actually about, which affiliates and counterparties matter, and where ambiguity remains is central to quality, not a preprocessing detail. It also clarified a boundary: in transaction-heavy cases, deterministic-first resolution pipelines still do the heavy lifting while the investigator calls that machinery and judges the result rather than reasoning over raw rows. The lesson is that agentic judgment and deterministic plumbing have to meet at the right boundary.
The platform, not the prompt, owns what must be true. Long investigations behave more like distributed systems than chats: tools fail, workers restart, some operations duplicate data if retried, facts surface unevenly, and required checks still have to happen. V2 leans on durable case infrastructure for this. Evidence moves out of the prompt and into durable state (documents become searchable files, transactions become queryable data), and investigators retrieve it when needed rather than dragging it all forward in context. Required work becomes explicit runtime structure: entity scope and dispatch are derived deterministically, each investigator carries a checklist of required work, checklist items must be resolved before results are accepted, and failed work stays visible as failed rather than silently disappearing. A checklist is not a reminder to the model. It is a way of making unresolved work unacceptable. This is the harness's job, and the subject of a dedicated piece later on.
Findings became an explicit substrate. V2 increasingly treats findings as explicit artifacts rather than incidental text. Investigators write findings that can be grouped, reviewed, and reconciled, and narrative generation becomes a synthesis layer downstream of that substrate rather than the only place the work meets. Once findings are explicit, contradictions are easier to detect, reconciliation can be targeted instead of rerunning everything, and the audit trail improves because the underlying work stays visible. The point is not producing one plausible report. It is producing a coherent, defensible case, which is a different and harder thing.
Reconciliation became a system concern. Rather than asking a central orchestrator to settle every contradiction from compressed summaries, V2 pushes conflicts back to the investigators that produced the findings, since they already hold the relevant context. The lead still owns the cross-case view and adjudicates one shared account, but the architecture stops treating reconciliation as just another prose problem.
Evaluation became part of the architecture. Once investigators choose how to research, what to inspect, and when to stop, reviewing the final output is not enough: a polished answer can hide incomplete research, unsupported claims, skipped required work, or conclusions stronger than the evidence. So the Evaluator, part of the platform's Trust Infrastructure, became a shared layer. The division is clean: the runtime proves that required work was covered visibly, and the Bretton Evaluator judges whether that work was trustworthy, with every material finding tied back to the source, tool call, or trace step behind it. The more agentic the system gets, the more it needs to evaluate the path, not just the answer. The Bretton Evaluator gets its own piece later in this series.
Experimentation became infrastructure. Many of the important V2 questions are architectural, not prompt questions. How many investigators should a case have? How much should one own? When does more parallelism help, and when does it just create a coherence tax? What should be compiled into instructions versus retrieved through tools, and what should be enforced structurally versus judged in evaluation? Those are too consequential to answer by intuition. The harness gives us a controlled way to run orchestration experiments, compare configurations, inspect traces, and measure dispatch compliance, context pressure, cost, and latency as the number of investigators grows. It let us test the topology question directly: one investigator per affiliate held up across repeated sweeps, without the context collapse many assume is inevitable. That is a far better basis for an architectural choice than argument from taste. Once the architecture becomes the product, experimentation infrastructure becomes part of the product.
What V2 taught us
The deeper lessons are about how agentic systems in regulated workflows have to be built.
- V1 did not possess adequate context management. In V2, using a virtual machine and orchestrator agent allows us to maintain context throughout the entire investigation.
- The unit of investigation was too small in V1. Too many narrow investigators create fragmentation, duplicated work, and weaker reconciliation. Coherence needs broader ownership.
- Reconciliation is a vital component of V2. The orchestrator now identifies contradictions between subagents and then reconciles the final report based on additional deep research.
- Not every hard problem belongs inside the model. Some of the workflow should stay deterministic-first and tool-exposed. The goal is not maximum autonomy. It is putting autonomy where judgment is valuable.
- Prompting is not enforcement. If something is required, important, or auditable, it should live in structure: config, tasks, checklists, findings, reconciliation, and runtime contracts.
- Task accuracy is not case accuracy. Long investigations compound small failures, and a system can look plausible while being incomplete, inconsistent, or unsupported.
- Evidence should be durable and inspectable. The agent reasons over the evidence. The harness stores the evidence, the checks that ran, what failed, and where the numbers came from.
- Evaluation matters more as agents get better, not less. The more freedom an investigator has, the more the system needs a disciplined way to judge whether that freedom was used well.
- Experimentation infrastructure is a competitive advantage. Once the important questions are architectural, the ability to run structured comparisons matters as much as the quality of any single prompt.
The main lesson
The biggest lesson from this progression is that agentic systems in regulated domains only get stronger when the surrounding product gets more disciplined. As the work gets deeper and the cost of an error rises, prompt quality alone stops being enough. The system has to get better at structuring investigators, separating shared technique from customer requirements, grounding work in evidence, preserving auditability, reconciling inconsistencies, and judging whether the result is actually trustworthy.
That is how these systems evolved for us at Bretton AI, and how they will keep evolving. The four primitives this series goes deep on next, Builder, the harness, the Evaluator, and the experimentation loop around them, are where the next gains come from.
The first of those is where every agent actually begins. Before an investigator can run coherently, keep evidence durable, or be judged against a standard, a customer's policies, SOPs, and risk logic have to become an agent that works the way the institution actually works. That translation is the subject of the next piece.
If you are deploying agents into compliance or financial operations, we should talk. And if you want to work on problems like these, our careers page is open.
