The AI Labor Stack: 13 Role Families Between a Model and an Outcome

A model can write an answer. A production system has to do something much harder.

It has to understand the right context, use tools, respect permissions, survive failure, fit a real workflow, produce evidence of quality, and create an outcome worth paying for. In consequential settings, someone also has to remain accountable when it gets things wrong.

That gap explains the strange new titles appearing across the software labor market.

They are not thirteen different ways to say “prompt engineer.” They are ownership boundaries around thirteen different bottlenecks.

The model is becoming a raw material. The new roles form around everything required to turn that raw material into accountable work.

This is a dependency map, not a prestige ladder. The lower layers make capability possible. The middle layers make it grounded, agentic, measurable, and safe. The upper layers make it fit human beings, organizations, and economically meaningful goals. Feedback then travels back down: deployment failures become evaluations; evaluations become data; data and environments improve the next model or system.

To keep this honest, I checked the taxonomy against the hiring market rather than extrapolating from fashionable language. Every role family below includes two openings that were live on employer career sites or their official applicant-tracking systems when I verified them on 3 September 2026.

This is not a made-up future-of-work story. These are real job openings in the market. The employers and responsibilities are observable; how I group them—and my forecasts about what happens next—are my research synthesis and remain open to correction.

The important thing is not to memorize those titles. It is to understand the bottleneck each function owns—and whether stronger models remove that bottleneck or merely move it.

The cards’ “likely path” labels are my base-case directions for the function, not promises about a particular title or its headcount. The horizons may also diverge: deployment demand can rise sharply in the near term even as common patterns become standardized and absorbed into broader jobs later.

The thirteen role families at a glance

These are role families, not a claim that every synonym is a separate profession. “Applied AI Engineer,” for example, can mean a product generalist at one company and something close to a customer-facing FDE at another. Read the responsibilities, not the badge.

Layer 1: Improve the model and the signal

Human Data Engineer

Real openings — verified 3 September 2026: Software Engineer, Research — Human Data at OpenAI and Human Data — Engineer at SpaceXAI. Both build feedback, labeling, evaluation, and quality systems that turn human judgment into model-training signal.

Modern AI systems do not improve through scraped data alone. They also need people to express preferences, demonstrate judgment, identify failure, compare trajectories, and translate tacit expertise into usable evidence.

The Human Data Engineer owns the machinery around that judgment: collection interfaces, labeling operations, quality controls, sampling, adjudication, privacy, and the pipelines that turn feedback into training or evaluation data. OpenAI’s Human Data engineering role describes exactly this kind of full-stack feedback infrastructure.

Stronger models should reduce commodity labeling. They will not eliminate the hard part: deciding whose judgment matters, capturing it without distortion, and separating a reliable signal from confident noise. The function moves up the value chain—from managing labels to engineering expert feedback systems.

Post-training Engineer

Real openings — verified 3 September 2026: Research Engineer, Production Model Post-Training at Anthropic and Member of Technical Staff — Post-Training and RL at SpaceXAI. The postings explicitly cover RLHF, preference optimization, reward modeling, evaluations, and production training pipelines.

Pretraining gives a model broad capability. Post-training shapes how that capability behaves.

This family works with reinforcement learning, preference optimization, synthetic data, reward signals, graders, behavioral evaluations, and the experimental loops that turn a vague requirement—“be more useful,” “follow instructions,” “use tools reliably”—into a measurable intervention. OpenAI’s Codex research role spans RL, data pipelines, graders, reward signals, evals, diagnostics, and production agent behavior.

Better models and better research tools will automate pieces of the work. But frontier post-training is likely to remain technically demanding and capital intensive. My bet is concentration, not disappearance: fewer organizations will train at the frontier, while many more product teams consume the behavior those specialists create.

AI Environment Engineer

Real openings — verified 3 September 2026: Research Engineer, Frontier Evals & Environments at OpenAI and Staff Software Engineer, Environments Infrastructure at Anthropic. They build RL worlds, agent runtimes, sandbox abstractions, recovery, and continuous-evaluation infrastructure.

An agent cannot learn complex work from a static answer key. It needs a world in which actions have consequences.

For a coding agent, that world might include a repository, terminal, compiler, tests, browser, and Git service. For an accounting agent, it might include a ledger, invoices, contracts, approval policies, an ERP, and deliberate exceptions. Environment Engineers build these sandboxes and simulations so agents can practice, be evaluated, and fail without damaging the real system.

OpenAI’s Frontier Evals & Environments role connects realistic RL environments directly to continuous evaluation and training. As agents become capable of longer and more consequential work, the environments must become richer—not simpler. This is one of the clearest candidates to expand.

Layer 2: Ground the system in the right truth

Knowledge Systems Engineer

Real openings — verified 3 September 2026: Software Engineer, Knowledge Systems at Exa and Research Engineer, Knowledge Team at Anthropic. The work includes entity resolution, truth discovery, information architecture, agentic search, knowledge graphs, retrieval, and ranking.

Models contain general knowledge. Organizations run on private, changing, contradictory, and permissioned knowledge.

The Knowledge Systems Engineer makes that reality usable by an agent. The work can include semantic models, entity resolution, provenance, temporal truth, document ingestion, retrieval, knowledge graphs, access control, and the construction of the exact context needed for a decision.

This is already visible in roles such as Anthropic’s current Research Engineer, Knowledge Team.

The shallow version of this job—split documents, create embeddings, retrieve five chunks—will become increasingly automatic. The difficult version becomes more important: Which source is authoritative? What was true on the date of the decision? May this user or agent see it? What happens when policy, contract, database, and human testimony disagree?

“Context engineering” and “memory engineering” may not survive as standalone titles. Their durable responsibilities are likely to fold into knowledge systems and agent platforms. The plumbing shrinks; truth, time, and authority remain.

Layer 3: Give the model a product and the product agency

Applied AI Engineer

Real openings — verified 3 September 2026: Applied AI Engineer, Enterprise Tech at Anthropic and Frontier Agents Engineer (Applied AI) at Scale AI. Both combine models, retrieval, agents, evaluations, product architecture, and production deployment.

The Applied AI Engineer is the generalist builder of the stack:

model + context + tools + workflow + interface + evaluations

This person turns model capability into a usable product, balancing probabilistic behavior with deterministic software. The role demands ordinary engineering discipline—data models, APIs, interfaces, latency, cost, observability—plus judgment about prompts, retrieval, tool use, fallbacks, and evaluations. Scale AI’s current Frontier Agents Engineer description shows how broad this work has already become.

As model APIs become easier to use, the “AI” modifier may fade. Prompt plumbing and framework-specific tricks will be less valuable. Product judgment, system design, integration, and the ability to decide where probabilistic software belongs will remain. This role does not vanish; it converges with excellent product engineering.

Agent Systems Engineer

Real openings — verified 3 September 2026: Software Engineer, Agent Systems at Serval and Software Engineer, Agent Infrastructure at OpenAI. They own orchestration, agent loops, runtime state, retrieval, integrations, and execution platforms.

A chatbot returns a response. An agent has to finish a job.

That means maintaining state, planning across steps, using tools, handling partial failure, recovering from bad actions, coordinating with other agents, escalating to a person, and knowing when to stop. The Agent Systems Engineer owns the harness that makes those trajectories possible.

Models will absorb more planning and orchestration. Code that manually decomposes every task into fragile prompt chains should shrink. What remains looks increasingly like backend and platform engineering for probabilistic workers: authority, state, idempotency, recovery, queues, transaction boundaries, and exception handling.

The title may become ordinary. The system problem will not.

Layer 4: Prove, operate, and constrain the work

AI Evaluation Engineer

Real openings — verified 3 September 2026: AI Evaluation Engineer at Zafin and AI Evaluation Engineer at Yes Energy. These exact-title openings own agent scenarios, benchmarks, regression suites, drift and failure analysis, continuous evaluation, and production-readiness evidence.

A deterministic unit test often asks whether a function returned the expected value. Agent evaluation asks whether a trajectory achieved the user’s objective correctly, safely, efficiently, and robustly across many plausible worlds.

The Evaluation Engineer turns intent into scenarios, datasets, graders, calibration studies, adversarial cases, error taxonomies, regression suites, and release decisions.

Models will get better at generating test cases and operating graders. That increases evaluation throughput; it does not answer the governing question: What counts as good? In finance, medicine, education, law, or safety-critical operations, defining valid evidence remains a domain and accountability problem. Evaluation is likely to expand and move closer to product strategy.

Agent Reliability Engineer

Real openings — verified 3 September 2026: AI Reliability & Monitoring Engineering Lead at Postman and Staff Software Engineer, AI Reliability Engineering at Anthropic. Their scope includes SLOs, behavioral and serving observability, failover, recovery, resilience testing, and incident response for AI systems.

The infrastructure can be healthy while the agent is doing something absurd.

Agent reliability therefore extends beyond uptime. It includes trajectory traces, tool failures, context regressions, model drift, latency and token budgets, retry storms, escalation rates, human overrides, and cost per successful task. It is SRE for probabilistic workers.

The ownership boundary is already becoming explicit in roles such as Anthropic’s AI Reliability Engineering.

As tools stabilize, routine triage will automate and the title may converge with SRE, observability, or platform engineering. The durable shift is that operations teams must measure behavioral correctness as well as machine health. A green dashboard cannot be the definition of a healthy service if the service is confidently taking the wrong actions.

AI Security & Safeguards Engineer

Real openings — verified 3 September 2026: Security Engineer, Agent Security at OpenAI and Red Team Engineer, Safeguards at Anthropic. They cover agent identity, sandboxing, runtime policy, prompt injection, authorization bypasses, adversarial testing, and safety monitoring.

An agent that can act can also be manipulated, overreach, leak data, misuse credentials, or follow a malicious instruction embedded in a tool result.

This family owns prompt injection defenses, least-privilege tool access, authorization boundaries, data exfiltration controls, adversarial testing, human approval points, monitoring, and incident response. It spans security engineering, safeguards, red teaming, safety, and governance because agency crosses all of those boundaries.

Current examples include Anthropic’s Red Team Engineer, Safeguards.

This is not one horizontal layer in practice. It is a constraint running through every layer of the pyramid. Stronger models may make defenses more capable, but stronger agency also expands the attack surface and the cost of a mistake. Expect this function to grow.

Layer 5: Fit the system to people and reality

Forward Deployed Engineer

Real openings — verified 3 September 2026: Forward Deployed Engineer at OpenAI and Forward Deployed Engineer at Anthropic. These exact-title openings own customer discovery, architecture, build, integration, rollout, adoption, and reusable lessons from the field.

The FDE thesis is that model capability is advancing faster than many organizations can absorb it.

The Forward Deployed Engineer crosses that last mile. OpenAI describes its FDEs as owning discovery, technical scoping, system design, build, and production rollout with strategic customers, then measuring success through adoption, workflow impact, and evaluation-driven feedback to product and research.

This is not merely API integration. The work sits inside legacy systems, ambiguous processes, organizational politics, security controls, domain rules, and frontline behavior. As models make prototypes easier, the cheap part of the role shrinks. The hard part becomes clearer: choosing the right workflow, redesigning it, integrating safely, changing how people work, proving value, and feeding repeated failures back into the platform.

That is why I expect the FDE function to deepen even if its title changes.

AI Interaction Designer

Real openings — verified 3 September 2026: Staff AI Interaction Designer at Spring Health and Product Designer, AI Experience at Omada Health. They define when AI should speak, act, remain quiet, show uncertainty, call tools, or hand control to a person.

Intelligent software introduces a design question ordinary interfaces rarely faced:

When should the system act, suggest, explain, ask, verify, wait, escalate, or remain silent?

The AI Interaction Designer shapes that policy through interface design, model behavior, feedback, permissions, uncertainty, and human handoffs. OpenAI’s Model Experience team describes this as turning a view of good human–AI interaction into model behavior through human data, evaluations, reward models, and post-training.

Better default models will eliminate a great deal of brittle conversation design. But the interaction problem remains, especially when an agent can take consequential action. The likely destination is not a permanent isolated guild. It is a deeper capability inside product, design, research, and engineering.

Learning Engineer

Real openings — verified 3 September 2026: Learning Engineer at LearnVector and Learning Engineer at Playlab. These exact-title openings combine teaching judgment with AI prototyping, assessment, feedback, quality gates, guardrails, and testing with learners or educators.

Generated educational content is becoming abundant. Human learning is not.

The Learning Engineer sits between pedagogy and engineering. The job is to decide when a learner should retrieve, produce, struggle, see a worked example, receive feedback, or be reassessed—and then encode that judgment into a system. LearnVector describes the aim as building systems in which the quality of excellent human teaching survives automation.

The operating loop is not “prompt → lesson.” It is:

learner state → task → evidence → diagnosis → intervention → reassessment → updated mastery

Stronger models will commoditize explanations, examples, and first-pass feedback. They make the Learning Engineer more, not less, accountable for the questions that matter: Did the learner understand? What evidence supports that claim? Is the intervention safe and appropriate? Who can change the mastery or reward policy? Manual content-authoring work shrinks; pedagogy, diagnosis, evidence, and learner protection remain.

Layer 6: Own the outcome

AI Engineering Leader

Real openings — verified 3 September 2026: Manager, Applied AI Engineering (Codex) at OpenAI and Engineering Manager — Applied AI at General Matter. Both lead teams while retaining responsibility for technical direction, evaluations, production handoff, adoption, and domain outcomes.

The apex is not “the boss of the pyramid.” It is the point at which someone accepts responsibility for the whole system.

An AI Engineering Leader may carry a title such as Applied AI Engineering Manager, FDE Manager, Agent Platform Manager, AI Solutions Engineering Manager, or simply Engineering Manager. The work is increasingly to manage a system composed of:

humans + agents + models + software + data + evaluations + controls

Stronger models may let smaller teams attempt more ambitious work. That does not reduce the scope of leadership; it can expand it. The leader must decide where automation belongs, which risks are acceptable, how authority is assigned, what evidence supports release, and whether the result is actually valuable.

The most valuable archetype may be the person whose title has not yet stabilized: a Domain + Systems + AI leader who understands an economically important field deeply enough to encode its knowledge, workflows, controls, evaluations, and judgment into a reliable system.

What stronger models actually make redundant

Models compress implementation. They do not eliminate the need for truth, authority, judgment, or accountability.

That distinction separates vulnerable specialties from durable ones.

Work built around temporary interface friction will be absorbed. Prompt syntax, manual context assembly, basic tool-schema wiring, and generic workflow automation are increasingly competencies inside broader jobs—not durable ownership boundaries by themselves.

Other functions will converge with established disciplines. Applied AI becomes product engineering. Agent systems become backend and platform engineering. AgentOps becomes SRE. AI interaction becomes product and design.

The functions tied to the external world deepen. Knowledge must still be current and permissioned. Evaluations must still represent real success. Security must still constrain authority. Successful deployment must still fit—or help change—an organization. Learning systems must still produce evidence of understanding. Leaders must still own outcomes.

And a few frontier functions—especially post-training at large scale—may concentrate in the organizations that can afford to operate them.

The likely future is not thirteen permanent new guilds. It is fewer people with broader scopes, more leverage, and clearer accountability for different parts of one system.

A better career question

Do not ask which new title will win.

Ask which durable constraint you are unusually equipped to own:

• private knowledge and temporal truth;
• long-running workflows and recovery;
• domain-valid evaluation;
• permissions and safe action;
• human adoption and organizational change;
• evidence of learning;
• or the accountable economic outcome itself.

The durable AI professional will not be the person who knows the cleverest prompt.

It will be the person who can close the gap between intelligence and a result that matters—and prove that the gap is actually closed.

This is a working map based on my research, not a claim that I have settled a fast-moving labor market. I am publishing it precisely because practitioners, hiring managers, researchers, designers, teachers, and operators will see things I have missed. I welcome corrections—and I will revise my view when better evidence warrants it.

Where do you disagree? What is inaccurate in this map, and which important role family is missing?