.png)
Third in a series on running AI agents in production inside a financial institution. This one is about how we do that repeatably, across hundreds of workflows and customers, without starting a brand new software project each time.
Inside Builder: how Bretton AI turns the way a customer works into a production agent, repeatably
Compliance and financial operations cover an enormous range of work: customer onboarding, transaction monitoring, adverse media, sanctions screening, periodic reviews, reconciliations, document processing, and investigations. Each needs different data, tools, policies, decisions, and outputs. And on top of that variety, every customer has its own vision and requirements for how the work should be done.
We’ve always been confident in our ability to build a strong agent for any one of those workflows. We do have a cracked engineering team, after all. The harder question was how to ensure our platform is truly functional at scale: we need to build hundreds of them, across different use cases and customers, without initiating a new software project. What we needed was a repeatable way to transform our customers’ workflow into an agent that meets their standard. That is what Builder is.
Building an agent used to be almost entirely manual
Customers often have most of the raw material we need: SOPs, policies, and examples of the work they want handled. Turning that material into an agent is our first challenge. Our deployment strategists have to understand the workflow, translate the SOP into agent behavior, identify the right capabilities, configure them, connect the relevant knowledge, define the expected output, and test the result end to end.
That worked beautifully when we were standing up a handful of agents. But as often happens at a fast-growing startup, our customers and use cases multiplied and this quickly became the bottleneck. Getting from a customer's documentation to a coherent first version of an agent took way too much manual work, and manual work will never scale into a platform.
An SOP is not the same as a spec
The first piece in this series made the point that building an agent is not translating an SOP into a prompt, it is reconstructing the operating logic behind the work. Builder is where that claim gets tested, because an SOP is written for someone who already knows the job.
Take a line an analyst reads without a second thought: check the corporate registry first, then cross-check the company website. A person fills in everything the sentence leaves out such as:
- Which registry?
- What to extract?
- What counts as an identity match?
- What to do when a source is down?
- Which source wins when two disagree?
The SOP does not spell any of that out because the analyst already has the context. An agent does not. So building the agent is the work of making all of that implicit judgment explicit, without flattening it into a single brittle instruction file.
Skills made capabilities reusable
As we built more agents, we kept implementing the same underlying capabilities: how to research a company, resolve an identity, evaluate a source, investigate adverse media, verify a sanctions match. We turned those into reusable skills, so a new agent no longer had to be taught the same underlying work from scratch.
That handled one problem and exposed another. Someone still had to read the customer's materials and decide which skills applied, how to configure them, what knowledge they needed, and which rules were specific to that customer. We had made the components reusable but we had not made the act of building the agent reusable, and that was the part actually consuming our experts' time.
What Builder does
Builder takes the materials a customer already has and turns them into a working agent configuration. Rather than treat an SOP as one large instruction, it decomposes the workflow into the layers that actually run the agent. These layers are designed to truly capture investigation intent and ensures that no requirement is missed. A vital step is conducting intelligent decomposition via their knowledge base and skills to enhance reusability while keeping the investigation properly targeted.
We also embed domain knowledge and learnings acquired via months of rigorous agent building and testing. This makes the platform effectively self-serve and allows our deployment strategists or customers to get a first agent ready in just a few minutes for practically any investigation.
All this is to say that we no never start from a blank prompt. We start from capabilities we already know how to run, and focus the custom work on what is genuinely different about this customer. That is the difference between configuring an agent and building one.
Making Builder reliable
Assembling an agent is one thing. Making the assembled agents behave predictably, at scale, over time, is another, and it took the most engineering hours.
Three guarantees mattered most. A customer-specific instruction sometimes has to change how a shared skill behaves without altering its core methodology. A published agent has to stay fixed even as its draft keeps evolving. And an improvement to a shared capability has to carry across every deployment without quietly introducing a regression somewhere else.
We built those into the system. Customizations across customers compile into the relevant skills and are verified before they run. Published agents execute against frozen configuration snapshots, so the version that was reviewed is the version that runs, which is what a model risk or audit team requires. And when the same behavior shows up across multiple customers, we promote it into a shared skill, doctrine, or configuration primitive rather than rewrite it again. That last part is what lets the system get better with every deployment instead of just bigger.
Build your first agent
Our own team now uses Builder as the starting point for every new deployment, and we are bringing that same workflow directly to customers. Compliance and operations teams can start from the procedures they already have, shape the parts that are specific to their business, and stand up agents without having to understand the machinery underneath.
That is the beauty of a platform: the workflow is yours to define with us. The system for turning it into a reliable agent, and keeping it reliable as everything around it changes, is ours to build and maintain.
If you want to see how Builder turns your existing procedures into production agents for compliance and financial operations, we should talk.
