Office Hours — What job titles and role definitions are emerging for engineers who primarily work with agentic AI systems?

What job titles and role definitions are emerging for engineers who primarily work with agentic AI systems?

The job market is settling into three distinct tracks, none of which map cleanly onto existing roles. What you call yourself depends less on the title than on which piece of the agentic stack you own.

The Planner-Executor Split

The most durable pattern emerging from production deployments is the separation between planning and execution. This split is creating two genuinely different skill sets. A Reasoning Systems Engineer focuses on frontier models, prompt engineering, and task decomposition—how to get Claude Opus 5 or GPT-5.6 Sol to think through hard problems and break them into solvable steps. An Agent Execution Engineer takes those plans and implements them with cheaper, faster models like Gemini 3.5 Flash or open-weight alternatives, handling tool integration, error recovery, and the orchestration mechanics that actually make things run.

Cursor’s recent work on agent swarms validates this split at scale. Their system uses frontier models to plan software tasks (breaking down “rebuild this component” into testable steps), then routes execution to cheaper models that handle the actual typing and testing. This division isn’t a bug—it’s the competitive advantage. Teams hiring for this structure need both types, and they’re different enough that a single hire rarely covers both competencies well.

The Agent Infrastructure Specialist

Someone needs to own the harness. As agentic systems move into production, a new archetype is crystallizing: the Agent Infrastructure Engineer or Agentic Systems Engineer. This person designs and maintains the machinery that keeps agents from melting down: monitoring and observability (what does a stuck agent look like?), error recovery and retry logic, cost controls and token budgets, memory management for long-lived agents, and tool discovery mechanisms that prevent agents from drowning in irrelevant options.

This role sits between traditional platform engineering and ML ops. You’re not building the model or the prompts. You’re ensuring that when agents break—and they will—you catch it fast, understand why, and don’t bankrupt the company in the process. Right now, most teams are improvising this role inside their existing ops structures. In 18 months it’ll be a standard hire at any company running autonomous workflows at scale.

The Agent Security and Governance Person

Claude Opus 5 hitting 0% prompt injection success on browser agents is a win, but it also exposes how much the attack surface has shifted. Teams are scrambling to hire Agent Security Engineers who understand threat modeling for autonomous systems—not traditional API security, but: how do you prevent agents from escalating their own permissions? What does safe tool access actually mean when an agent can chain calls across multiple systems? How do you audit an agent’s decisions retroactively when they happened in the dark?

This role requires someone comfortable with both offensive and defensive thinking. You’re threat-modeling agentic workflows the way security teams used to threat-model authentication flows. The difference is speed—agents can explore the attack surface in hours, and the attack surface keeps changing faster than frameworks stabilize.

The Agent Evaluator

With SWE-Bench Pro broken (OpenAI found ~30% of tasks are malformed), teams can’t rely on published benchmarks anymore. Enter the Agent Evaluation Engineer—someone who builds domain-specific evals on your actual workload. Databricks benchmarked coding agents on its million-line codebase and found that open-weight GLM-5.2 matched Claude Opus 4.8 on their actual tasks while costing less. No public benchmark would have shown that. This person writes evals that matter, interprets the results honestly, and prevents teams from overweighting vendor marketing.

What’s NOT Yet Standardized

The titles are still messy because the work is still crystallizing. You’ll see:

• “Agentic AI Engineer” (generic, covers too much ground to be useful)
• “AI Agent Architect” (sounds important, often means “runs demos and writes planning docs”)
• “Autonomous Systems Engineer” (overloaded with robotics baggage)
• “LLM Systems Engineer” (confuses infrastructure with agentic work)

The disconnect is that the industry hasn’t yet separated the specialized skills because most orgs still have only one or two people touching agents at all. As scale increases, the roles will fork. A team running a single coding agent might have one person wearing four hats. A team running dozens of autonomous workflows across different domains needs dedicated specialists.

Concrete Pattern: Cursor’s Hiring Reflects This

Cursor’s agent team is structured around the planner-executor model: frontier model specialists design task decomposition and reasoning prompts, while execution engineers optimize routing to cheaper models and debug the orchestration layer. They’re not hiring for “LLM engineers”—they’re hiring for specific parts of the agentic pipeline. This is becoming the template.

Bottom line: If you’re building with agents, the three roles worth hiring for now are: someone who can architect agentic workflows and work with frontier models, someone who can build the infrastructure and monitoring that keeps agents running reliably, and someone who can design realistic evals on your actual workload rather than trusting benchmarks. The titles will standardize in another 12 months, but the skill separation is already real.

Question via Hacker News