The Agent Stack Has Arrived: AI Engineering Beyond the Model

The model is becoming the engine. The employable work is increasingly the rest of the car.

Across 4,142 active technology roles at 111 companies, our current catalog contains 371 explicit LLM roles, 321 AI Agents roles, 130 RAG roles and 91 MCP roles. More important than the individual totals is the way those requirements travel together: 115 roles pair AI Agents with LLM, 93 pair LLM with RAG, 52 pair MCP with Python and 46 pair AI Agents with MCP.

Those are not four names for the same trend. They are four layers of a new application stack. The companies hiring for it need engineers who can give a model context, let it act, observe what happened, constrain the dangerous edges and measure whether the system is getting better.

That is a much larger job than writing prompts.

First, what the numbers actually measure

We count a technology only when it is extracted from the requirements, responsibilities or explicit skill context of an active posting. We do not label every role at an AI company as an AI role, and we do not turn a marketing sentence into a hard requirement.

The July 2026 snapshot is:

LLM — 371 roles across 78 companies. The broad model-application layer.

AI Agents — 321 roles across 75 companies. Systems expected to choose or sequence actions.

RAG — 130 roles across 47 companies. Retrieval and grounding as a named implementation concern.

MCP — 91 roles across 46 companies. A new integration contract already spread across a surprisingly broad employer base.

Python — 915 roles. Still the dominant implementation language around the stack.

TypeScript — 228 roles and Node.js — 173. The product-engineering path into the same market.

A mention is not proof that every engineer in the role will build every layer. It is evidence that employers have started naming the layers separately. That vocabulary change matters: markets usually name a component after it becomes difficult enough to require ownership.

The five planes of a production AI application

The cleanest mental model is not a pile of frameworks. It is five planes with different failure modes.

1. The model plane: capability under uncertainty

The model generates, classifies, plans or chooses. It is powerful, probabilistic and replaceable. Model selection matters, but it is only one engineering decision among latency, cost, context limits, privacy, tool support and failure tolerance.

This is why “knows GPT” is not a durable skill. A strong engineer can define the task, construct a stable interface around the model and swap the model without rebuilding the product. The valuable abstraction is not a vendor SDK; it is a contract for inputs, outputs, uncertainty and fallback behavior.

2. The context plane: RAG is a search system

RAG is often described as “give the model company documents.” In production it is an information-retrieval system with a model attached.

The pipeline has separate decisions: how content is chunked, indexed and permissioned; how a query is rewritten; which sources are searched; how candidates are ranked; how much context is admitted; and how the answer cites or abstains. Each decision can fail while the final prose still sounds fluent.

That distinction explains the strong LLM + RAG pair in 93 live roles. Employers are not buying a checkbox. They are buying engineers who can reason about retrieval quality before asking the model to reason about an answer.

Microsoft makes the same separation in its RAG design and evaluation guidance: retrieval has its own metrics, including recall and ranking quality, while the answer must be evaluated for groundedness, relevance and correctness. A grounded answer can still be wrong. A correct answer produced from bad retrieval can still be fragile.

3. The action plane: MCP turns integrations into contracts

An agent becomes useful when it can do something: read a customer record, inspect a repository, create a ticket, run a query or request approval. Before MCP, every tool integration tended to become a bespoke adapter with its own discovery, authentication and payload conventions.

The Model Context Protocol architecture standardizes the boundary between an AI host and external capability servers. Its three server primitives are a useful engineering map:

Resources expose context the application can read.

Prompts expose reusable interaction templates.

Tools expose actions the model may request.

MCP does not decide how an agent should think. It does not make an unsafe tool safe. It does not replace application authorization. It gives integrations a common contract so teams can spend less time rebuilding plumbing and more time defining what may happen through that plumbing.

The hiring signal is early but real: 91 roles name MCP, spread across 46 companies. More than half of those MCP roles pair it with Python, and 46 pair it directly with AI Agents. A standard that appears across half as many employers as roles is not trapped inside one vendor or one unusually large hiring program.

4. The orchestration plane: workflow before agent

An agent is not simply a longer prompt. It is a feedback loop: decide, act, observe, update and stop.

That loop creates flexibility and also creates new ways to waste money, loop forever, choose the wrong tool or take an action on a false premise. The best production design therefore starts with the least agentic architecture that can solve the task.

Anthropic draws a practical line in Building effective agents: workflows follow predefined paths, while agents dynamically choose their process and tools. A deterministic sequence is easier to test and cheaper to operate. Agent autonomy earns its cost only where the path cannot be known in advance.

A good architecture ladder is:

One model call with a structured output.

A fixed workflow with explicit branches.

A router that selects among fixed workflows.

A bounded agent with a small tool set and hard stop conditions.

A multi-agent system only when specialization and handoffs create measurable value.

Skipping directly to step five is not ambition. It is removing observability before the product has earned complexity.

5. The reliability plane: evals, traces and guardrails

Traditional software tests ask whether the same input produces the expected output. AI systems need that, plus a way to judge outputs that may be different and still acceptable.

The reliable loop is:

collect representative tasks from production behavior;

define task-specific success criteria;

score the final result and the path that produced it;

inspect failures by retrieval, routing, tool selection and policy compliance;

add the failure to a regression set;

repeat continuously.

OpenAI recommends this evaluation-driven cycle in its evaluation best practices, including production-shaped datasets, automated scoring and human calibration. For agents, trace evaluation matters because a correct answer can arrive through an unsafe or accidental path.

Guardrails solve a different problem. An eval tells you how a system performed. A guardrail or approval decides whether an action may proceed. The highest-risk checks belong next to the tool that creates the side effect, not only at the beginning or end of an agent run. OpenAI documents this boundary in its guidance on guardrails and human approvals.

What the pair signals reveal

The graph is more informative than the leaderboard.

Agents + LLM — 115 roles. “Agent” is becoming a concrete application architecture, not a decorative synonym for AI.

LLM + RAG — 93 roles. Grounding remains the most established production companion to model work.

MCP + Python — 52 roles. Python owns much of the integration and orchestration surface.

Agents + MCP — 46 roles. Standardized tools and agentic execution are growing together.

Agents + TypeScript — 42 roles; Agents + Node.js — 34. Product engineers have a credible second entrance that does not require becoming model researchers.

Agents + Kubernetes — 46 roles. Once agent workloads matter, teams need deployment, isolation, scaling and observability like any other distributed system.

The agent stack is not replacing software engineering. It is absorbing more of it.

The role hidden behind the buzzwords

The strongest candidate for this market can answer questions at three altitudes.

At product altitude: What user decision improves? What happens when confidence is low? Where must a person approve? What latency is acceptable?

At system altitude: Which steps are deterministic? What state survives a retry? How are tools authorized? How does the system prevent duplicate side effects? What is the stop condition?

At model altitude: What context is needed? How will retrieval be evaluated? What belongs in a structured output? Which failures require a different model and which require better application logic?

That combination explains why backend, platform and full-stack engineers are showing up in agent postings. They already understand APIs, queues, permissions, state, retries and operational failure. The new work is learning how probabilistic decisions change those familiar systems.

A build plan that proves real competence

Do not build another chat box over a PDF. Build one narrow system that has consequences and can explain itself.

Weeks 1–2: establish a measurable workflow

Choose a task with a clear result: triage an incident, research a company, reconcile invoices or prepare a code-change plan. Implement it first as a fixed sequence with structured inputs and outputs. Record latency, token cost and failure categories.

Weeks 3–4: make retrieval observable

Add a small corpus with permissions and citations. Measure whether the right evidence appears before measuring prose quality. Keep failed queries. Demonstrate one change to chunking or ranking that improves a retrieval metric rather than “feels better.”

Weeks 5–6: add one action boundary

Expose a read tool and a write tool, ideally through MCP. Put authentication and authorization outside the model. Require approval for the write. Make retries idempotent. Log the exact arguments and result.

Weeks 7–8: add bounded agency

Let the system choose among a small tool set, but cap iterations, time and spend. Define when it must stop, ask for help or fall back to a deterministic path. Test adversarial tool results and malformed context.

Weeks 9–10: build the eval set

Turn every interesting failure into a case. Grade retrieval, tool choice, argument quality, policy compliance and final correctness separately. Show the before-and-after scorecard in the repository.

That project demonstrates the actual stack: not that a model can respond, but that a system can operate.

How to read an agent-stack posting

Treat the nouns as clues to ownership:

LLM usually means model integration, structured outputs, latency and cost.

RAG means search, data quality, permissions and evaluation.

MCP means capability contracts, tool schemas and security boundaries.

Agents means orchestration, state, retries, stop conditions and traces.

Kubernetes or cloud means the experiment has become a service someone must operate.

Evals or guardrails mean the team has already discovered that demos and production are different products.

The posting with the longest buzzword list is not automatically the best role. The best role can explain which layer is broken, what success means and what the engineer will own.

The durable bet

Framework names will turn over. Model rankings will turn over faster. The durable skills are the boundaries between components: retrieval quality, tool contracts, workflow design, authorization, observability and evaluation.

The market data already reflects that shift. The interesting number is not merely 371 LLM roles or 321 agent roles. It is the growing intersection between model work and ordinary production engineering.

The agent stack has arrived. Its best engineers will look less like prompt specialists and more like unusually careful systems builders.

---

Method: exact normalized skill mentions and pair intersections across 4,142 active postings at 111 companies in the ApplyDjin catalog, July 13, 2026. Counts overlap because one posting may name multiple technologies. Employer totals use companies with at least one active role.