Agentic AI & LLMs
By Sagar Shankaran, Founder of CallSphere
The concrete skills and role shifts teams need so Claude agents and skills work across an organization — upskill vs. hire, and the roles that emerge.
Key takeaways
When a company decides to put Claude agents into real workflows, the first thing that breaks is not the model. It is the org chart. The team that wrote a clever prompt in a notebook now has to ship an agent that other people depend on, that touches production systems through MCP servers, and that has to be evaluated like any other piece of software. The skills that made someone a strong individual contributor on a traditional codebase do not automatically transfer. This post is about the concrete capabilities people have to build, the roles that quietly change, and how to staff an agentic program without pretending you can hire your way out of it.
A traditional backend engineer reasons about deterministic systems: given an input, the function returns the same output. Agentic systems built on Claude are probabilistic and tool-using. The same prompt with the same context can take a different path through its tools on two runs. That single fact reshapes what "competent" means. Engineers now have to reason about distributions of behavior, not single traces, and they have to design guardrails that hold even on the runs they did not personally observe.
The second shift is that the interface is natural language plus tool schemas, not a typed API. A skill author is effectively writing instructions that a capable but literal colleague will follow. The skill that works is the one that anticipates ambiguity, states preconditions, and fails loudly. People who are good at writing runbooks and incident postmortems tend to be unexpectedly good at this; people who only ever wrote terse internal code sometimes struggle, because they assume the reader already shares their context.
Across teams shipping Claude agents, a few durable roles keep appearing under different names. Below is how the work tends to split once an agentic program is past the prototype stage.
flowchart TD
A["Domain expert / PM"] --> B["Skill author writes instructions & scripts"]
B --> C{"Touches prod systems?"}
C -->|Yes| D["Agent engineer wires MCP servers & permissions"]
C -->|No| E["Ship as read-only skill"]
D --> F["Eval owner builds test suite"]
F --> G["Agent operator monitors prod traces"]
G --> H["Feedback loop back to skill author"]The skill author turns tribal knowledge into a folder of instructions, scripts, and resources that Claude can load when relevant. This person needs strong written communication and domain fluency far more than deep systems programming. The agent engineer owns the integration surface: which MCP servers are connected, what scopes those tools have, and how the agent is sandboxed. The eval owner is the role most teams forget to staff and most regret skipping — they build the test cases that gate every change. Finally the agent operator watches production, the way an SRE watches services, and routes problems back to the right author.
Hear it before you finish reading
Talk to a live CallSphere AI voice agent for home services in your browser — 60 seconds, no signup.
The instinct to spin up a separate "AI team" is usually a mistake. The people who understand your billing logic, your claims process, or your support edge cases are your existing staff. An agent that automates a workflow needs that domain knowledge encoded correctly, and a newly hired generalist will spend months learning what your senior support lead already knows. The faster path is to teach your domain experts the small surface of agentic concepts they need: how skills are discovered and loaded, how to write a clear tool description, how to read an eval failure.
That said, you do need at least one or two people with genuine depth in agent system design — usually engineers who have already shipped something with the Claude Agent SDK or built real MCP servers. Their job is partly to build and partly to teach. A healthy program looks like a thin layer of agent specialists supporting a much wider group of upskilled domain owners, not a walled-off lab.
Here is a sequence that gets a mixed team productive without drowning them in theory. Run it as a multi-week program, not a single workshop.
The trace review in step six is the highest-leverage habit on the list. Reading what the agent actually did, including the boring successful runs, builds intuition faster than any lecture. A team that spends fifteen minutes twice a week reading real traces together develops a shared sense of what good agent behavior looks like, and that shared sense is what lets them disagree productively when they later argue over a skill change. Without it, every review devolves into competing intuitions that no one can ground in evidence.
Engineering managers feel this shift acutely. The old unit of work was a pull request from a person; the new unit increasingly includes work proposed by an agent that a person reviewed. Managers who try to measure agentic teams by lines of code or tickets closed measure the wrong thing entirely, because the agent can generate volume cheaply. The signal that matters is whether the team is shipping agents that hold up in production — whether the eval suites are growing, whether escalations are trending down, whether the trace reviews surface fewer surprises over time.
That means managers themselves need a small but real fluency in the concepts: enough to ask whether a proposed agent has an eval set, enough to push back when someone wants to give an agent write access without a containment plan, enough to recognize when a "quick prompt fix" is actually papering over a missing test. A manager who cannot ask these questions cannot effectively lead an agentic team, no matter how strong their people are. This is the most overlooked skill shift, because it lands on the people least likely to take a training course.
Still reading? Stop comparing — try CallSphere live.
See the home services AI agent handle a real call — complete, industry-specific, and live in your browser. No signup.
When you do hire, ignore résumés that list "prompt engineering" as a headline skill and look for evidence of system thinking. The interview signal that correlates best with success is whether a candidate, given a fuzzy task, instinctively asks about failure modes, tool permissions, and how success will be measured — before writing a single prompt. Below is a comparison of where to invest.
| Capability | Hire for it | Train for it |
|---|---|---|
| Agent system design & eval | Yes — scarce | Slowly |
| Domain knowledge of your workflows | Rarely available | Already have it |
| Skill / instruction writing | Nice to have | Very teachable |
| MCP / tool integration | Helpful | Teachable with a mentor |
| Production monitoring habits | SREs already have it | Reuse existing on-call |
Usually no. Building agents on Claude is a software and systems-design discipline, not a model-training one. You need people who can design tool boundaries, write clear instructions, and build evals — closer to a strong backend or platform engineer than to a research ML scientist.
Yes, and they often should. An Agent Skill is a folder of instructions, scripts, and resources that Claude loads when relevant, and the instruction-writing part rewards domain expertise and clear writing far more than programming. Pair them with an engineer for anything that touches production tools.
A motivated team running the checklist above tends to ship its first genuinely useful internal agent within a few weeks, and reaches steady-state competence — including eval and monitoring habits — over a couple of months. The bottleneck is usually building review and eval discipline, not learning the tools.
The ability to reason about failure before success. People who instinctively ask "what happens on the bad run, and who notices" build agents that survive contact with production. That mindset is teachable, but it has to be deliberately taught.
CallSphere takes these same staffing and skill patterns into voice and chat — agents that answer every call, use tools mid-conversation, and book real work around the clock, backed by the eval and monitoring discipline this post describes. 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.
Written by
Sagar Shankaran· Founder, CallSphere
LinkedInSagar Shankaran is the founder of CallSphere, where he builds production AI voice and chat agents deployed across healthcare, hospitality, real estate, and home services. He writes about agentic AI, LLM engineering, and shipping voice agents that handle real calls in production.
See how AI voice agents work for your industry. Live demo available -- no signup required.
Which solar roles change shape in 2026, what a new designer needs taught in week one, what stops being a hiring requirement, and the ramp-time arithmetic.
One reschedule text hits your scheduler, package balance, tutor shift and invoice. Here is what MCP changed for tutoring and test-prep center owners in 2026.
AI codes the bank feed now. What a bookkeeping firm should teach a new hire in week one, what comes off the job ad, and what a shorter ramp is worth per hire.
AI adoption hit 66% of US small firms but 70% say staff need training. How the import coordinator desk at an NVOCC changes, and what to teach in week one.
How MCP lets an AI assistant write lease abstracts into Yardi Voyager and VTS instead of a browser tab, and where a lease administrator still has to sign off.
Stop juggling callbacks and double-bookings. See how 2026 AI books nail appointments straight into the calendar you already use, around the clock.
© 2026 CallSphere Inc. All rights reserved.
Made within San Francisco
Watch how CallSphere handles real customer calls, schedules appointments, and processes payments — live.
Try Live DemoBook a DemoCalculate Your ROI