What We Learned Building a Bank Operations Agent

Our Bring-Your-Own-Bank model lets customers connect directly to their own sponsor banks through our Payments API. It's powerful, but it also means every support question sits at the intersection of our platform, a partner bank's quirks, and whatever the customer's engineers actually built. Answering these questions well has always required someone who can move fluidly between Sentry, Notion, Linear, our codebase, and a handful of internal playbooks, usually a Technical Account Manager (TAM), often under time pressure.

So we built a Bank Operations Agent to sit in that workflow to do the cross-system legwork before a human ever has to.

This is one instance our AI as Infrastructure projects we're investing in more broadly: giving agents real tool access across our own systems. Our Bank Operations Agent is one of a few agents we've deployed internally this way, as we look to free our teams from repetitive work so they can focus on what actually needs a human.

How it actually works

The agent is built to decompose a request, decide which systems are relevant to each part, and query them in parallel rather than sequentially, which is a big part of where the speed comes from. The agent is built using MintMCP Coworker agents and uses tool access that runs through MintMCP, which is what lets one agent reach across our full toolset without us hand-building a bespoke integration for each system:

• Notion is a first-pass source for Bank Technicals and playbooks: how a connect link behaves, what rails a bank is supposed to support. But the agent treats it as potentially stale by design, and never asserts support from Notion alone.
• Devin (coding agent) is the authoritative source for what's actually built, searching config files, feature flags, guards, and importers directly in the codebase. If Notion says "supported," Devin confirms it against reality. If Devin finds no guard or no config, the agent notes the search scope rather than treating absence as proof.
• Hex is where the agent runs read-only queries directly against production and analytics data (Postgres, ParadeDB, Snowflake), so it can check which customers are actually using a capability in production and where there's a gap between what's built and what's actually deployed.
• Linear is roadmap and issue history: prior incidents for a customer, whether something's already planned, and the canceled or stalled tickets that explain why a capability doesn't exist yet.
• Sentry is the first stop for any active error, the actual exception type, message, and stack trace, so the agent isn't reasoning from a vague symptom description or a playbook heuristic.
• Zendesk is for ticket lookup and for drafting new tickets on Category 3 escalations, drafted, never auto-filed. A human always approves before anything goes out.
• Slack is how the agent reads full thread context before responding, and replies in-thread so the conversation doesn't fragment.

Underneath all of that is one consistent rule: each tool has a specific epistemic role, and the agent doesn't let one substitute for another. Notion tells you what's supposed to be true. Devin and Hex tell you what's actually true. Sentry tells you what just happened. The agent is built to keep them separate, and to escalate rather than guess when even that isn't enough to close the gap.

Five shapes of questions

After enough triage history to see what actually comes through, five patterns show up again and again.

1. Verify-before-you-send. A lot of what comes through is someone about to tell a customer or partner something and wanting it checked against reality first. A TAM drafted a full description of a bank connection (SFTP, ISO 20022, which PAIN files flow in which direction) before sending it to a partner bank on a customer's behalf, and wanted every line confirmed. A separate question asked us to confirm that payment status and webhooks were "fully supported with no caveats" before that language went out. A third asked for a review of customer-facing language about connection timelines before it shipped. All three are pre-flight checks to catch a claim before it becomes a promise.

2. Active errors, with investigation already attempted. These rarely show up as a bare "it's broken." Usually someone's already dug in. One report involved a payment action the bank confirmed receiving and processing, which still wasn't showing up correctly on our side, and the person had already ruled out the obvious cause before asking. Another report traced a fallback failure to a default field value that a different bank's validation rejected, which led to three concrete resolution paths already scoped rather than an open-ended "what's wrong."

3. Bank-driven changes that need engineering sign-off. When a bank changes its own infrastructure, retiring a server or splitting into separate endpoints, someone still has to validate that a proposed code change actually covers everything the bank now requires, then review the fix.

4. Migration and build-out asks. Some of the highest-context messages in the channel are asked to help move a customer off a deprecated, one-off setup onto the standard model, or to scope out what a migration would even take.

5. Straight engineering coordination. These look like code review requests, intent checks on a pull request, and questions aimed at another engineer rather than at a customer's problem at all.

Today the agent handles the first two well, and the last three are where we're actively working on, and getting there doesn't mean pulling humans out of the loop.

Even as coverage grows, the design stays the same: a human reviews anything that leaves the agent's own state, and the agent's job is to make that review faster and better-evidenced.

Where it actually gets hard

Simple cases save time just by being fast, but the complex ones save time by being thorough. Below are a few examples where our agent tackled some tougher questions:

• A bank connection error looked, on the surface, like a generic "something went wrong" during a bank connection sync. Resolving it meant checking Sentry for the real exception, pulling the Notion playbook on connect-link behavior, running a code scan to rule out a pending-request guard (there wasn't one), and searching Linear for prior incidents with the same bank. The question turned out to bundle an active error, a process question, and a false premise that needed debunking, all at once. The answer landed on a specific, checkable cause: FIB accounts likely not yet existing at the bank, tied back to an open ticket.
• A bank check API question inverted the usual premise problem: a client assumed a capability wasn't built when in fact two separate configurations already existed. But the harder problem underneath was an ambiguity that no amount of code-reading could resolve: "bank check" could mean an existing SFTP channel or a newer REST product, and only the TAM could say which one the customer actually meant. Along the way, the agent also surfaced a manual ops gap in check returns and two open incidents that hadn't been connected to the original question. That one is still open, pending TAM confirmation, by design. We'd rather the agent hand back a well-scoped, evidence-backed open question than force a guess on something it has no way to resolve from code or docs alone.
• A bank feature question started from a client's assumption that a feature was fully supported without any caveats. Verifying that claim against the actual code and data surfaced two caveats that weren't in anyone's mental model: L3 data isn't processed, and non-ACH L2 rejections map to a failed status rather than returned. Being ahead of these assumptions is what lets us avoid customer dismay once they’re in prod.

This case is also where the agent's output stopped being just an answer and started improving the underlying product. The webhook sub-question in this thread exposed that our answers were leaning on internal state-machine language customers don't actually see. We changed the standard going forward, and internal state-machine terms have since been replaced with customer-facing event names in every webhook answer, everywhere. Therefore, we were able to find a systemic gap in how we communicate and closed it permanently.

What it's actually worth

For simple process and webhook questions, the agent saves roughly 30 to 60 minutes each, the time a TAM would otherwise spend searching Notion, digging through old Slack threads, and often still pinging someone to confirm.

For the complex, multi-system cases, the savings are bigger and less obvious: 2 to 4 hours of elapsed time, more when engineering coordination would have been needed. As a result, engineers aren't pulled into a Slack thread to run a search they could've been running against their own roadmap. When a case does need an engineer, it arrives with the Sentry exception already pulled, the relevant code already scanned, and the prior incidents already surfaced, so the person picking it up starts from a scoped, evidenced problem instead of a cold start.

Between both, we’ve found the agent catching the confident wrong answer before it goes out the door, and in the best cases, turning what it finds into a permanent fix rather than a one-off correction.

On the second time, it’s important to emphasize that agent time is abundant in a way engineer time isn't. An engineer pulled into a thread is, by definition, pulled off whatever project they were focused on, so the instinct is to patch the immediate symptom and get back to it. The agent doesn't have that tradeoff. It can spend the extra passes to trace a question or a bug to its actual root cause instead of stopping at the first answer that resolves the symptom.

To be clear, that's not the agent operating unsupervised. When the fix touches actual code, it still goes out as a PR, reviewed and merged by a human like any other change. What's different is what shows up for review: a scoped, evidenced fix instead of a raw bug report, because the agent had the time to do the legwork.

What's next

The agent already takes some action on its own: drafting Zendesk tickets, updating its own instructions when a TAM correction reveals a gap, the agent is always improving with feedback from a human.

The natural next step is extending that same pattern: more of the routine follow-through done automatically. None of that changes the core design principle, though: the agent should get faster and broader at gathering evidence and proposing action, without ever getting more willing to guess or to ship something a human hasn't seen.

As we continue refining our Banks Operations Agent, we’ll also share more about the other agents we’ve built.