Scaling Claude Agents Across a Financial Institution

The first Claude agent in a bank is a project. The fifth is an organizational problem. Somewhere between them, most institutions hit a wall: every team builds its own agent, its own prompts, its own connectors, its own ad-hoc logging, and suddenly the risk function is staring at a dozen ungoverned systems that no one can audit consistently. Scaling agentic AI across a financial institution is not about building more agents faster — it is about building them on a shared foundation so that the hundredth agent is safer and cheaper than the first. This post is about that foundation.

Why does the second wave of agents cause chaos?

The chaos comes from duplication without standardization. The first team that ships an agent solves a hundred small problems — how to connect to the core banking system, how to log every action immutably, how to gate high-stakes steps, how to run evals. When the second and third teams start from scratch, they re-solve those same problems slightly differently, and now you have three incompatible logging formats, three permission models, and three eval approaches. Multiply by a dozen teams and the institution has lost the one thing finance requires: consistency you can prove to a regulator.

The failure is organizational, not technical. Each individual agent might be fine; the portfolio is ungovernable because nothing is shared. The fix is to recognize early that the connectors, controls, and evals are not features of one agent — they are infrastructure that every agent should inherit. A platform team that owns this shared layer turns the second wave from a chaos multiplier into a force multiplier, because every new team starts where the last one finished.

What does a shared agent platform look like?

A shared platform for financial-services agents has a few well-defined layers that teams build on rather than rebuild. A connector layer of vetted MCP servers exposes core systems — the ledger, the CRM, the document store — with permissions and audit logging already enforced, so no team writes its own integration to a regulated system. A controls layer provides the action-gating, the immutable logging, and the output checks as defaults every agent inherits. A skills layer captures reusable institutional knowledge — how this bank writes a SAR narrative, what its suitability rules are — as Agent Skills that any team's agent can load.

flowchart TD
  A["Team needs new agent"] --> B["Reuse shared MCP connectors"]
  B --> C["Inherit controls & logging"]
  C --> D["Load shared skills & policies"]
  D --> E["Add team-specific logic"]
  E --> F{"Passes central eval gate?"}
  F -->|No| G["Fix & resubmit"]
  G --> F
  F -->|Yes| H["Deploy under central monitoring"]
  H --> I["Feedback improves shared layer"]
  I --> B

The diagram captures the central idea: a new agent is mostly assembled from shared, pre-governed parts, with each team adding only its specific business logic on top. The eval gate and the monitoring are centralized so the risk function has one place to look, not a dozen. Scaling agentic AI across an organization is the practice of moving from per-team reinvention to a shared, governed platform where each new agent inherits proven connectors, controls, and evals. That inheritance is what makes the hundredth agent safer than the first.

How do you govern many agents without a bottleneck?

Centralizing controls risks creating a central bottleneck where every agent waits in a queue for the platform team's approval. The way out is to centralize the standards and decentralize the building. The platform team owns the guardrails, the eval framework, and the shared connectors; the business teams own their agents' logic and ship within those rails. Approval becomes mostly automatic: if your agent passes the central eval gate and uses only sanctioned connectors, it ships, because the standards did the governing rather than a human reviewer.

This is the same federated model that works for software platforms generally, and it works here for the same reason: it scales review by encoding it into the platform instead of into people. A risk committee that would drown reviewing a dozen bespoke agents can comfortably oversee a hundred agents that all share the same controls and surface the same exception signals. The governance scales because the variety is bounded — every agent is a variation on a trusted template, not a unique snowflake.

How do you avoid token costs spiraling at scale?

At one agent, inference cost is a rounding error; at a hundred, it is a budget line that leadership will scrutinize. Scaling cleanly means baking cost discipline into the platform. Default model routing — small fast models for routine extraction, capable models only for genuine reasoning — applied as a platform standard prevents every team from independently over-provisioning. Shared retrieval that fetches only relevant context, rather than dumping whole document stores into each call, keeps token usage proportional to the work.

The multi-agent question gets sharper at scale too. A multi-agent run consumes several times the tokens of a single agent, so a platform that makes multi-agent fan-out the easy default will see costs balloon. The discipline is to make the cheap single-agent path the default and require a deliberate justification for multi-agent designs reserved for high-stakes thoroughness. When cost-aware patterns are the platform's defaults rather than each team's afterthought, the institution scales to many agents without the bill scaling out of control.

How do you keep quality consistent as you grow?

Consistency at scale comes from a shared eval culture, not from hoping every team is careful. The platform should provide a common eval harness and a library of adversarial financial test cases, so that "good enough to ship" means the same thing in the lending team and the fraud team. When a failure is found anywhere, it becomes a test case in the shared library, and every future agent is measured against it — institutional learning compounds instead of staying trapped in one team.

The cultural piece is a community of practice across the teams building agents. Regular forums where teams share what worked, what broke, and what they added to the shared skills layer turn isolated lessons into organizational capability. Tools like Claude Code and the Agent SDK make the shared layer concrete, but the durable advantage is social: an institution where every team building agents learns from every other team building agents will out-execute one where each reinvents the wheel in isolation. Scaling without chaos is, in the end, a knowledge-sharing achievement as much as a technical one.

Frequently asked questions

Should we build the platform before the first agent?

No — build the first agent first, then extract the platform from it. The connectors, controls, and evals you build for agent one become the shared layer for the rest. Trying to design a platform in the abstract before you understand the real problems usually produces something nobody wants to use.

Who should own the shared platform?

A dedicated platform team partnered closely with risk and compliance. They own the connectors, controls, and eval framework as a product with the business teams as customers. The key is that they enable building rather than gatekeep it, so teams ship fast within rails instead of waiting in an approval queue.

How do we prevent one bad agent from undermining trust in all of them?

Shared controls and centralized monitoring contain blast radius: because every agent inherits the same guardrails and surfaces the same signals, a problem is caught and isolated quickly rather than spreading. Consistent governance is exactly what lets one team's mistake stay one team's mistake.

Bringing agentic AI to your phone lines

Growing from one agent to many on a shared, governed foundation is precisely how CallSphere scales voice and chat agents across teams and channels — reusable tools, shared controls, and central monitoring, without the chaos. See the platform approach at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.