I've been managing engineering teams for long enough to know what happens when a new technology layer shows up: the job titles lag the reality. Cloud computing was mainstream well before "Cloud Architect" stopped being a novelty on a resume. DevOps was a philosophy before it was a department, and by the time companies were hiring "DevOps Engineers," the people who'd been doing the work were the ones defining what the role actually meant.
I think we might be at that point with agentic AI. After three months of building with Claude Code every day (40+ projects, thousands of prompts, more debugging sessions than I want to admit), I've started to notice patterns in what makes the difference between a productive session and a frustrating one. And some of those patterns feel like they could be the seeds of roles that don't quite exist yet.
I'm not suggesting these are all standalone job titles waiting to be posted on LinkedIn. More likely they're skills and competencies that will be valued inside roles we haven't fully defined yet, the way "understanding distributed systems" wasn't a job title but became a prerequisite for half the senior engineering roles that followed.
I could be wrong about some of these. A few I've sort of lived: rewriting CLAUDE.md files over and over feels a lot like what I'm calling "context engineering" below, and debugging a Cognito auth loop at 11pm has the texture of "agent failure analysis." Others are more speculative, extrapolated from a trajectory I think I see but can't be sure about. Take them as one person's field notes, not a prediction.
The obvious-ish layer (but deeper than people think)
Context Engineers. This might be the most underrated one. Not prompt engineering (that term is already dated). I mean people who deeply understand how to structure what an agent knows at every point in a workflow. What goes in the system prompt, what's in CLAUDE.md, what's dynamically injected, how to manage the sliding context window as a conversation grows, when to summarize vs. keep verbatim. This is analogous to how memory management was a deep skill in early systems programming. The person who really gets context will produce agents that seem magical compared to naive implementations using the same model.
Agent Orchestration Architects. Different from your "sub-agent" builder. This is the person who thinks about the topology of multi-agent work. When do you fan out vs. stay serial? How do you decompose a problem so agents don't step on each other? How do you handle partial failures in a parallel agent run? This is distributed systems thinking applied to AI. It's the difference between someone who can spin up a Kubernetes pod and someone who designs the whole distributed architecture.
The "nobody's talking about these yet" layer
Codebase Ergonomics Specialists. People who make codebases agent-friendly. Today, a well-structured codebase benefits human developers. But agents have different needs. They navigate by search, they're sensitive to naming conventions, they benefit from certain documentation patterns that humans wouldn't bother with. Someone who deeply understands how agents traverse and comprehend code could restructure a codebase to dramatically improve agent effectiveness. Think of it like SEO but for your own codebase, making it discoverable and comprehensible to your AI collaborators.
Agent Failure Analysts / Debuggers. When an agent produces a subtly wrong result or goes off the rails three steps into a five-step plan, why? This requires a weird hybrid of debugging skill, understanding of model behavior, and the ability to read an agent trace the way a performance engineer reads a flame graph. This person can look at a failed agent run and say "it lost the thread here because the context got polluted by that large file read two turns back." This skill barely exists yet and will be in enormous demand.
Specification Writers. Not product managers, not technical writers. A new thing. People who can write specs that serve double duty: readable by the team AND precisely executable by agents. The art of writing a feature spec that an agent can pick up and implement with minimal ambiguity. This is harder than it sounds because natural language is inherently ambiguous, and these people will develop an instinct for where agents misinterpret and how to preempt it. Think of it like the gap between writing pseudocode and writing compilable code, but for natural language.
Eval Engineers. How do you know your agent setup is actually good? Not just "it worked this one time" but systematically measuring quality, catching regressions when you change a system prompt, A/B testing different agent configurations. This is the QA discipline reinvented for non-deterministic systems. Today almost nobody does this rigorously. The people who figure it out will be invaluable because they'll be the ones who can say "this change to our agent workflow improved correctness by 15% across 200 test cases" instead of vibes.
Token Economists. Understanding the cost/quality/speed tradeoff space intimately. When to route to Haiku vs. Sonnet vs. Opus. How to restructure a workflow to cut costs 10x without degrading output. How to audit where tokens are being wasted. As agent usage scales, the difference between a naive implementation and an optimized one could be orders of magnitude in cost. This is the cloud cost optimization specialty reborn.
The further horizon
Human-Agent Workflow Designers. Where do you put the human checkpoints? How much autonomy does the agent get before requiring approval? How do you design the interaction so the human is reviewing meaningful decisions, not rubber-stamping busywork? This is a UX discipline that doesn't exist yet. Get it wrong and you either bottleneck everything on human approval or you let agents run wild. The best people at this will understand both human psychology and agent capabilities deeply.
Agent Security / Guardrail Specialists. As agents get more tool access (shell, APIs, databases, deployment pipelines), the attack surface grows enormously. Prompt injection through code comments. Agents accidentally leaking secrets. Supply chain risks from agent-installed dependencies. This will become its own security discipline, distinct from traditional appsec.
Domain Bridge Specialists. Not just "knows healthcare" or "knows finance." The person who deeply understands a regulated domain AND agent capabilities AND can build the constraints, validation layers, and domain-specific tooling that makes agents safe and effective in that domain. The intersection is rare and incredibly valuable.
Agent Observability / AgentOps. Monitoring, tracing, and debugging agent systems in production. Dashboards showing agent success rates, cost per task, failure patterns, drift over time. This is the SRE/DevOps specialty adapted for agent infrastructure.
The meta-prediction
I think the biggest shift is that the unit of expertise moves up a level of abstraction. Today's "REST API guru" becomes tomorrow's "person who can specify and orchestrate agents to build, test, deploy, and monitor REST APIs end-to-end." The underlying skill (knowing what good REST design looks like) doesn't go away. It becomes the taste and judgment layer that sits on top of agent execution.
The people who thrive won't be the ones who can type the fastest or hold the most code in their head. They'll be the ones with the best judgment about what to build, the clearest communication of intent, and the deepest understanding of where agents need guardrails vs. freedom.