Hiring for Claude Managed Agents: New Skills to Learn

When a team decides to run Claude Managed Agents on its own infrastructure — self-hosted sandboxes that execute the agent's code, and MCP tunnels that bridge those sandboxes back to internal systems — the first surprise is rarely the model. It is the org chart. The agent works on day one. What breaks is that nobody owns the sandbox image, nobody can read an MCP server log, and the person who wrote the agent's instructions has never designed an eval in their life. The capability is real, but the team is staffed for a previous era of software.

This post is about the human side of that shift: what skills actually have to exist on a team before self-hosted Claude agents become a reliable production capability instead of a clever demo, and how hiring and role definitions move to support it. It is not a generic "AI will change everything" essay. It is a concrete inventory of the competencies you need and where to find or grow them.

Key takeaways

• Running self-hosted Claude agents demands four skill clusters most teams lack: sandbox operations, MCP server authoring, eval engineering, and agent SRE.
• The scarcest hire is not a "prompt engineer" — it is someone who can reason about blast radius across a process boundary (the sandbox) and a network boundary (the tunnel).
• You can grow most of these skills internally; the fastest path is pairing a backend engineer with a security engineer on one MCP server.
• Write job descriptions around capabilities (eval design, least-privilege tunnel scoping) rather than tool names that will be stale in a year.
• Avoid the trap of hiring a single "AI engineer" to own everything — agent reliability is a cross-functional discipline.

Why the skill gap shows up only in production

A Claude Managed Agent is straightforward to prototype. You describe a task, give it a few tools through MCP, point it at a sandbox, and watch it work. The prototype hides the operational surface area because in a prototype the sandbox is your laptop, the MCP server runs as you with your credentials, and the only eval is "did it look right." Every one of those shortcuts becomes a job function when you move to production.

The self-hosted variant raises the stakes further. You are no longer renting a managed runtime; you own the container image the agent executes inside, the network path the MCP tunnel takes back to your databases, and the identity the agent presents to internal services. Each of those is a distinct discipline with its own failure modes. The gap is invisible in the demo and unavoidable in week three, which is exactly why teams under-hire for it.

For grounding: a Claude Managed Agent is a Claude-driven agent whose execution, tool access, and lifecycle are operated by your team rather than run only inside a vendor's hosted environment — meaning your team owns the sandbox it runs in and the connectors it reaches through.

The four skill clusters you actually need

Map the work to people before you map it to tools. These four clusters cover the real surface area of a self-hosted agent platform.

flowchart TD
  A["Agent task defined"] --> B["Sandbox ops: image, limits, isolation"]
  A --> C["MCP authoring: tools, scopes, schemas"]
  B --> D["Agent SRE: run it, watch it, page on it"]
  C --> D
  A --> E["Eval engineering: prove it works"]
  E --> F{"Quality gate passed?"}
  F -->|No| A
  F -->|Yes| D
  D --> G["Reliable production capability"]

Sandbox operations. Someone has to own the container or microVM the agent runs in: the base image, the resource limits, the egress rules, what filesystem it can touch, how secrets get injected without leaking into logs. This is platform engineering, not ML. A strong Kubernetes or container-platform engineer learns it fastest.

MCP server authoring. The tunnel is only as safe as the MCP server on the other end. Writing one means designing tool schemas a model can use unambiguously, scoping each tool to least privilege, and validating every argument the agent sends. This blends backend engineering with security review.

Eval engineering. The single highest-leverage skill, and the rarest. An eval engineer turns "the agent should handle refunds correctly" into a runnable test set with graded outcomes, so a prompt or model change can be measured instead of vibed. Without this role, you cannot safely change anything.

Agent SRE. Agents fail in ways services do not: they loop, they call a tool 40 times, they stall mid-task. You need someone who instruments runs, sets budgets, defines what "page me" means for an agent, and writes the runbook for a stuck sandbox.

What to put in the job description

Hiring managers reach for "prompt engineer" because it is the term they have heard. It is the wrong anchor. The durable competency is reasoning about boundaries — the process boundary the sandbox enforces and the network boundary the tunnel crosses — and proving behavior with evidence. Write the role around that.

Here is a capability-based snippet you can drop into a req. It screens for the thinking, not the tooling:

Role: Agent Platform Engineer

You will:
- Own the sandbox image Claude agents execute in (limits, egress, secrets)
- Author and review MCP servers that expose internal tools to agents,
  with least-privilege scopes and strict argument validation
- Build eval suites that gate agent behavior changes before release
- Define SLOs, budgets, and runbooks for agent runs in production

We screen for:
- Designed an isolation boundary (container/microVM) under threat
- Turned a fuzzy quality goal into a graded, automated test set
- Debugged a system across a network boundary you did not fully control

Notice there is no model name, no SDK version, and no "X years of prompt engineering." Those details age out. The screening signals — isolation under threat, graded test sets, cross-boundary debugging — stay relevant across model generations and are far easier to interview for honestly.

Grow or buy: a decision table

Most teams cannot hire all four clusters at once, and they should not try. The good news is that three of the four grow well internally from people you likely already have. Use this to plan.

Skill cluster	Best internal source	Grow or buy?	Time to competent
Sandbox operations	Platform / infra engineer	Grow	Weeks
MCP server authoring	Backend + security pairing	Grow	Weeks
Eval engineering	QA or data-minded engineer	Grow, sometimes buy	Months
Agent SRE	Existing SRE / on-call eng	Grow	Weeks

The pattern that works fastest: take one backend engineer and one security engineer and have them ship a single real MCP server together, end to end, with scopes and validation. That one project teaches both the tunnel discipline and the threat model, and it produces an artifact the rest of the team can copy. Eval engineering is the one cluster where an external hire often pays off, because the muscle of designing graded test sets is genuinely scarce.

Common pitfalls when staffing for self-hosted agents

• Hiring one "AI engineer" to own everything. Agent reliability is cross-functional. One person cannot simultaneously be the sandbox owner, the security reviewer for every MCP tool, and the eval author. They will become a bottleneck and burn out.
• Treating prompt writing as the core skill. Prompting matters, but a perfectly worded instruction running in an unbounded sandbox with an over-scoped tunnel is a liability, not a feature.
• Skipping the eval hire because the demo passed. Without graded evals, every change is a gamble and every regression is discovered by a user. This is the most common reason self-hosted agent projects quietly stall.
• Assigning agent on-call to people with no runbook. An SRE paged for a looping agent at 3am with no budget alert and no kill switch will do the wrong thing. Build the runbook before you build the rotation.
• Writing reqs around tool names. "5 years of MCP" is nonsense in 2026. Screen for the underlying capability so the hire survives the next model and the next protocol revision.

Stand up the team in five steps

1. Name a single owner for the sandbox image — limits, egress, secret injection — before any agent ships.
2. Pair a backend and a security engineer to build one production MCP server end to end as the reference implementation.
3. Hire or designate an eval engineer and require a graded test set for every agent task before it goes live.
4. Fold agents into your existing on-call rotation with budgets, a kill switch, and a written runbook for stuck runs.
5. Rewrite open reqs to screen for capabilities, not tools, so the team survives the next model generation.

Frequently asked questions

Do we need to hire a dedicated prompt engineer?

Usually no. Prompt quality matters, but it is one skill among several and rarely the bottleneck. The roles that gate success are sandbox ops, MCP authoring, eval engineering, and agent SRE. Spread prompt-writing across the engineers who own those areas rather than isolating it in one title.

Can our existing SRE team run Claude agents?

Mostly yes, with a short ramp. Agents introduce new failure modes — loops, tool storms, stalls — but the core discipline of instrumentation, budgets, alerts, and runbooks is exactly what SREs already do. Give them a kill switch and a budget alert and they adapt quickly.

What is the single most valuable skill to add first?

Eval engineering. Once you can grade agent behavior automatically, every other improvement becomes measurable and safe to ship. Without it, you are flying blind and will discover regressions through user complaints.

How long until a small team is production-ready?

If you grow internally from existing infra, backend, security, and SRE people, a focused team can reach a reliable first production agent in roughly a quarter — most of that time spent on evals and the reference MCP server, not on the model.

Bringing agentic AI to your phone lines

CallSphere puts these same agentic-AI disciplines to work on voice and chat — assistants that answer every call and message, reach into your tools mid-conversation, and book work around the clock. See the live system 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.