Hiring and Skills for Claude Agents in Financial Services

The bank or fintech that buys a Claude license and assigns it to "whoever has spare cycles" almost always stalls. Not because Claude can't do the work, but because nobody on the team has the specific blend of skills agentic systems demand: prompt design, eval engineering, tool plumbing, and the regulatory instinct to know when an automated answer is a compliance event. Deploying Claude across a lending desk, a claims team, or a trading-ops function is less a software install and more a quiet reshaping of who you hire and what your current people learn.

This post is about that human side. What does a financial-services team actually need to learn before Claude Code, the Claude Agent SDK, and MCP servers turn into shipped, audited, money-touching workflows? And which roles do you create versus retrain?

Why the skill gap bites hardest in finance

Every industry adopting agentic AI hits a learning curve, but financial services adds three multipliers. First, the cost of a wrong answer is asymmetric: a hallucinated balance, a misquoted APR, or a fabricated regulatory citation isn't an embarrassment, it's a reportable problem. Second, the data is governed by overlapping regimes such as SOX, GLBA, and a maze of state rules, so the people building agents must understand data lineage as well as prompts. Third, the workflows are deeply tool-mediated: a useful Claude agent in finance rarely just talks, it queries a core banking system, pulls a credit file, and writes to a case management tool.

That means the scarce skill isn't "writing good prompts." It's the ability to reason about a Claude agent as a system that combines a model, a set of tools exposed through MCP, a permission boundary, and an evaluation harness, all sitting inside a regulated control environment. Few people arrive pre-built with all of that, so you assemble it.

The four new competencies your team must build

Across the financial teams shipping real Claude deployments, four competencies show up repeatedly. They map cleanly onto either new hires or retraining tracks.

flowchart TD
  A["Existing finance team"] --> B{"Skill gap audit"}
  B -->|Prompt & eval design| C["Agent engineer track"]
  B -->|Tool & MCP plumbing| D["Integration engineer track"]
  B -->|Risk & controls| E["AI risk officer role"]
  B -->|Domain judgment| F["SME reviewer pool"]
  C --> G["Shipped Claude workflow"]
  D --> G
  E --> G
  F --> G

The agent engineer owns the prompt and the eval suite. This person treats system prompts as versioned artifacts, builds golden datasets of real cases, and uses Claude's own grading to score outputs. They need fluency in how Opus, Sonnet, and Haiku differ on cost and capability, because routing a routine balance-inquiry to Haiku and an exception narrative to Opus is a design decision with a budget attached.

The integration engineer wires Claude to the bank's systems through MCP servers and the Agent SDK. Their hardest work is not the happy path but the permission model: which tools an agent may call, what scopes a token carries, and how a tool call is logged so an auditor can reconstruct it. This is where traditional backend skill transfers well, but the engineer must learn the agentic idioms of tool definitions, structured returns, and Skills that teach Claude how and when to use each tool.

Roles you create versus people you retrain

You will probably not hire all four competencies fresh. The realistic split: retrain your strongest backend and data engineers into integration and agent-engineer roles, and create one or two genuinely new positions. The most important net-new role is an AI risk officer who sits between the build team and second-line compliance. A junior version of this exists in many model-risk-management groups already, but agentic systems need someone who understands prompts and tools, not just statistical model validation.

The other net-new function is less a hire and more a structure: a subject-matter-expert reviewer pool. These are existing lenders, adjusters, or ops specialists who spend a few hours a week labeling agent outputs and writing eval cases. They are the institutional knowledge that turns a generic Claude deployment into one that actually reflects your underwriting policy. Treat their review time as a funded responsibility, not a favor.

What "prompt engineering" really means here

Hiring managers often write "prompt engineering" on a job description and expect a single skill. In a regulated agent deployment, the work breaks into several distinct abilities. There is instruction design: writing system prompts that encode policy, refuse out-of-scope requests, and cite sources. There is context engineering: deciding what goes into Claude's window, how documents are retrieved, and how the 1M-token context is used without drowning the model in noise. And there is eval engineering: building the test sets and graders that prove a change is an improvement and not a regression.

The teams that succeed treat these as separate, teachable skills with their own rubrics. A practical onboarding path is to have new agent engineers first write evals for an existing agent before they touch its prompt, so they learn the workflow's failure modes before they try to fix them.

A pragmatic 90-day skilling plan

For a team starting close to zero, a workable sequence is: weeks one to three, get everyone hands-on with Claude Code on a sandboxed, non-production task so the mechanics of subagents, skills, and MCP feel normal. Weeks four to eight, pick one narrow, high-volume workflow, and have your retrained agent engineer and integration engineer build it end to end with SME reviewers writing eval cases in parallel. Weeks nine to twelve, run the AI risk officer through a full control review of that one workflow, documenting tool permissions, logging, and human-escalation paths.

The point of going narrow first is that the skills compound. By the time the second workflow starts, your people have a reusable eval harness, a known-good MCP integration pattern, and a control template the risk team has already blessed. The second deployment moves several times faster than the first.

Frequently asked questions

Do we need to hire data scientists to deploy Claude in finance?

Usually not in the classic sense. Deploying Claude agents is closer to software and systems engineering than to statistical modeling. You benefit more from strong backend engineers who can learn prompt and eval design than from researchers building models from scratch. A model-risk specialist is valuable for governance, but the build team is mostly engineers.

What is an AI risk officer in this context?

An AI risk officer is a role that owns the controls, permissions, logging, and escalation design for agentic AI systems, translating between the engineers building Claude agents and the compliance and audit functions that must sign off on them. In finance this person bridges model-risk-management practice and modern agent tooling.

Can existing employees learn this, or is external hiring required?

Most of it is learnable. Your strongest backend and data engineers can become agent and integration engineers within a quarter of focused, hands-on work. The one role most teams hire or heavily develop is the AI-risk function, because it sits at the intersection of agent internals and regulatory controls, which few people already combine.

Which Claude model should new agent engineers learn first?

Start with Sonnet for everyday agent work because it balances capability and cost, then learn when to escalate to Opus for hard reasoning and exception handling, and when to drop to Haiku for high-volume, simple steps. Understanding this routing is itself a core agent-engineering skill.

Bringing agentic AI to your phone lines

CallSphere puts these same skills to work on voice and chat — agentic assistants that answer every call, pull data through tools mid-conversation, and book work around the clock. See how a deployed agent behaves in production 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.