Scaling Claude Across a Financial Institution

The first Claude deployment in a bank is usually a triumph. One team — credit, or claims, or compliance — finds a workflow, builds a sharp agent, and posts results that make leadership want it everywhere. Then the request goes out: roll it out across the firm. And this is where many programs quietly fall apart, not because the technology fails but because what worked as one team's craft project collapses under the weight of ten teams, twenty connectors, and a hundred slightly different prompts that nobody can govern. Scaling agentic AI across an institution is a platform problem, and treating it as a copy-paste exercise is how you create chaos.

Why the second team is harder than the first

The first team succeeds because a few committed people own everything end to end — the prompts, the connectors, the evals, the relationships with the business users. None of that ownership transfers automatically. The second team has different systems, a different risk profile, and no one who has internalized the hard-won lessons of the first. If each team rebuilds from scratch, you get ten incompatible agents, ten audit approaches, ten places where a prompt-injection defense might be missing, and no one with a coherent view of the firm's total exposure.

The way out is to recognize early that you are not scaling an agent — you are scaling a capability. A working definition: scaling an agentic program means turning one team's working solution into a shared platform of reusable components, governance, and expertise that many teams can build on without each reinventing the foundations. The unit of reuse is not the finished agent; it is the parts.

The platform layer that makes scale sane

Underneath the individual agents, a small set of shared components does the heavy lifting. Reusable Agent Skills capture the firm's recurring knowledge — how to read a credit agreement, the house style for a regulatory memo, the bank's product taxonomy — as folders Claude loads when relevant, written once and used everywhere. A shared catalog of MCP servers, each connecting Claude to a core system with least-privilege access already baked in, means the second team does not rebuild the connection to the document store or the policy database; they request access to a connector that is already governed and audited.

flowchart TD
  A["Team 1 ships a working agent"] --> B["Extract reusable parts"]
  B --> C["Shared skills library"]
  B --> D["Governed MCP connector catalog"]
  B --> E["Shared eval & audit framework"]
  C --> F["Team 2 composes a new agent"]
  D --> F
  E --> F
  F --> G["Central platform team governs & observes all"]

The third shared component is a common eval and audit framework. Every team's agent passes the same baseline safety and quality gates, logs to the same audit standard, and reports into the same observability surface. This is what lets a central function answer the question a regulator will eventually ask — "show me every agentic system that touches customer decisions and how each is controlled" — without a frantic scramble across ten teams. The platform is what turns a sprawl of experiments into a governable estate.

Ownership: the center-of-excellence pattern

Scale needs an owner, but the wrong ownership model strangles it as surely as no ownership lets it sprawl. A central platform team that builds every agent becomes a bottleneck the business routes around. A pure free-for-all produces the chaos described above. The pattern that works is a thin center of excellence that owns the platform — the skills library, the connector catalog, the eval framework, the governance bar — while the individual teams own their own agents built on top of it. The center provides paved roads; the teams drive on them.

This federated model scales because it distributes the building while centralizing the standards. The center is small and high-leverage: it does not need to know the underwriting team's domain, only to ensure the underwriting team's agent meets the firm's safety, audit, and reuse standards. When a new team arrives, they get a starter kit — vetted connectors, baseline skills, a passing eval template — and reach production in a fraction of the time the first team took, because they are composing proven parts rather than discovering them.

Avoiding the chaos failure modes

Three failure modes recur as programs scale, and each has a structural fix. Connector sprawl — every team building its own access to the same system — is prevented by the governed catalog and a rule that new connectors go through the center. Prompt and skill drift — the same task done ten subtly different ways — is contained by the shared skills library and periodic review of where teams have diverged and why. And governance blind spots — an agent shipped without the audit trail or eval gate — are closed by making the platform the only paved path to production, so that meeting the standards is the easy default rather than an extra step teams skip under deadline.

The cultural fix matters as much as the structural one. Teams reuse shared components only when reuse is genuinely easier than rebuilding, so the center's real job is to make the paved road faster than the dirt path. When the skills library is well-maintained and the connector catalog is rich, the second and tenth teams reach for it eagerly. When the shared parts are stale or hard to use, teams route around them and the sprawl returns. Scaling without chaos is, in the end, an act of relentless platform craftsmanship in service of the teams building on top.

Frequently asked questions

How do you scale Claude from one team to the whole organization?

Stop scaling the agent and start scaling the capability. Extract the reusable parts — Agent Skills, governed MCP connectors, and a shared eval and audit framework — into a platform, then let each new team compose agents from proven components rather than rebuilding the foundations. A thin center of excellence owns the platform; teams own their agents.

Why is the second team harder than the first?

The first team's success rests on a few people owning everything end to end, and that ownership does not transfer. Without shared components, every new team rebuilds prompts, connectors, and governance from scratch, producing incompatible agents and no firm-wide view of risk. A platform layer is what makes the second and tenth teams fast and safe.

Who should own agentic AI at scale in a bank?

A thin, high-leverage center of excellence that owns the shared platform — the skills library, connector catalog, eval framework, and governance bar — while individual business teams own the agents they build on top. The center provides paved roads; it does not build everything, or it becomes a bottleneck.

How do you prevent connector and prompt sprawl?

Make the platform the only paved path to production. Route new connectors through a governed catalog, capture recurring knowledge in a shared skills library, and keep that road faster and easier than rebuilding. Teams reuse shared components only when reuse genuinely beats reinventing.

Bringing agentic AI to your phone lines

CallSphere brings this platform discipline to voice and chat — shared skills, governed connectors, and one observability surface so agents scale across teams and channels without chaos. See it live 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.