Most integrations stall on data, not APIs

Fifth in a series on running AI agents in production inside a financial institution. This piece is about how we get our customers in production as quickly as possible via our integration capabilities.

We integrate Bretton AI with banking systems typically within a week

An AI agent only creates value if it can reach the systems where the work happens. In financial services, that means case-management platforms, KYC and KYB systems, screening vendors, warehouses, transaction stores, document repositories, internal APIs, and legacy applications that predate all of them.

The integration challenge is all about identifying the right path quickly, getting the right access, and agreeing on exactly what data needs to move. Those are organizational problems as often as technical ones, and they are where timelines actually go. So we built our process around two things that remove most of that uncertainty before implementation starts: a small number of repeatable integration patterns, and a clear checklist of what we need from the customer up front. In recent deployments, that combination has taken integrations from first access to production in about a week.

Three questions decide an integration

Before any implementation, we assess a workflow against three questions. Answer them, and most of the ambiguity is gone.

What triggers the work? A webhook, a scheduled API pull, a file feed, a database query, or a browser workflow: how Bretton AI learns there is a case to run.

What data does the case need? The fields the agent needs to complete the work, where they live across systems, and how records link together (a customer ID to an account ID to a transaction history). The data question usually carries the most hidden complexity.

Where does the result go? What Bretton AI returns and to which system: findings, disposition, notes, status, and supporting evidence written back to the system of record.

Everything else in an integration is implementation detail around those three answers.

Why we can move quickly

We do not treat every integration as a new engineering project. We reuse the same core patterns across deployments: maintained connectors for common financial-services systems, direct access to warehouses and data infrastructure, configurable API tools for straightforward endpoints, browser-based workflows for systems without usable APIs, and custom connectors when none of those fit.

Just as important, we separate the reusable integration from the customer-specific workflow. Once we understand how a platform authenticates, paginates, and structures its data, we do not relearn it for the next deployment. The remaining work is narrower: which data this customer needs, how it maps into the agent, and what has to be returned. That separation is where the speed comes from.

A recent customer deployment shows the shape of it. For a digital-asset platform integrating a Persona, we added a native connector for the provider, then a customer-specific fetch specification to pull exactly the data that workflow required and a write-back specification to return results the way the customer needed them. From the moment the customer shared a sandbox, API keys, and data requirements, the integration was complete in about a week, expedited by a standardized connector framework we reuse across deployments.

What we need from our customers

The fastest integrations start with a complete picture of the workflow. A realistic sample case is especially valuable: documentation tells us what a system is supposed to return, while a real payload tells us what the integration actually has to handle.

The integration paths

There is no single architecture that works for every institution. We choose the simplest path that gives the agent reliable access to the required data.

Pre-built connectors. For systems we already support, we reuse an existing connector and configure it for the workflow. This is the fastest path, because the underlying system integration already exists. The customer-specific work is mostly mapping fields and choosing which operations the workflow needs.

Data infrastructure. Sometimes the cleanest path is straight through the institution's data layer: warehouses, databases, data lakes, SFTP feeds, scheduled files. This is often best for investigation workflows that need deep historical data or information spread across several operational systems. Rather than force every query through a case-management platform, the agent works from the source that already consolidates the information.

Configured APIs. A straightforward API often needs no custom connector. If an endpoint returns structured data with predictable authentication, we expose it to the agent as a governed tool through configuration. This works well for internal services and vendor APIs where the task is simply: given this identifier, retrieve this data. No one-off application code per endpoint.

Browser-based workflows. Not every important system has an API, which is common with older case-management and back-office platforms. For those, the agent works through the existing user interface, so a missing API does not automatically become a blocker.

Custom connectors. When a system has unusual authentication, complex sequencing, or non-standard payloads, we build a dedicated connector. The important thing is that we know this early. The discovery checklist tells us whether an existing path fits or whether engineering is genuinely required before the timeline is set.

These paths combine. For a sponsor bank working with a fintech partner, we extended a Unit21 connector to ingest the partner's unusual-activity reports and built a native client to pull additional enrichment data from Google Drive. The team started working real cases within a week of getting access to the data, because most of the connector work already existed and only the customer-specific pieces were new.

What actually slows integrations down

The biggest delays are always unanswered questions. The system owner that’s unclear. The sandbox access that takes weeks to arrange. The alert payload that happens to carry a different identifier than the transaction system expects. A write API assumed during scoping that doesn’t actually exist. A platform that is mid-migration during implementation.

Every one of these is solvable. They become expensive only when they surface after the build has started. Our process is built to surface them first, which is why the checklist comes before the timeline, not after it.

What success looks like

A successful integration has three things clear before production: how work enters Bretton AI, where the agent gets the data it needs, and what happens to the result when the work is done. Once those are defined, the integration becomes a choice among known patterns rather than an open-ended discovery exercise. We reuse what is reusable, surface the unknowns early, and build custom infrastructure only when the workflow actually requires it.

Reaching the work is the precondition for everything else in this series. Once an agent can get to the systems where the work lives, the questions that remain are whether it does the work correctly, and whether it keeps doing so as those systems change. Those are the subjects of the pieces on the Bretton Evaluator and how that works in action.

If you are exploring an agent deployment in compliance or financial operations, reach out. We can map the systems involved, identify the fastest integration path, and make clear what your team would need to provide to start.