Context Engineer Job Description

A context engineer decides what a large language model sees each time it is called. For a simple chatbot that might be a system prompt and a few retrieved paragraphs. For an agent that works through a long task, it is a moving stack of instructions, conversation history, memory entries, tool definitions, tool results and notes the agent wrote to itself, all competing for a fixed number of tokens. The context engineer designs the rules that build that stack, measures whether they work, and fixes them when the model forgets a constraint, contradicts itself or follows the wrong instruction.

Anthropic's engineering team, in a September 2025 post, defines context engineering as the set of strategies for curating and maintaining the optimal set of tokens during LLM inference, and calls it the natural progression of prompt engineering. The same post explains why the job exists. As the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases, an effect the post calls context rot. Context, in Anthropic's words, must be treated as a finite resource with diminishing marginal returns. Filling a large window is easy. Filling it with the right things, in the right order, is the work.

Where the job starts and stops

The role is easiest to define by its neighbors. Prompt work concentrates on the wording of instructions. Retrieval engineering builds the indexes, embedding pipelines and search services that return candidate documents. The context engineer owns the assembly step that sits after both: which retrieved passages make the cut, how much of the budget goes to history versus tool output, what the agent remembers across sessions, and what gets summarized or thrown away when the window fills.

The daily toolkit

Much of the work is software. Context engineers write the orchestration code that builds each request, in languages such as Python or TypeScript, on top of model provider APIs and agent frameworks. They configure servers built on the Model Context Protocol, an open standard whose specification lets a server offer resources (context and data for the user or the model), prompts (templated messages and workflows) and tools (functions for the model to execute). They shape how tool results come back, because a raw API response can spend a large share of the budget on fields the model never needs.

Anthropic's post names three techniques for long-running agents: compaction, which summarizes a conversation nearing the context window limit and restarts with the summary; structured note-taking; and sub-agent architectures, which give focused tasks to agents with their own windows. It also describes "just in time" strategies, where an agent keeps lightweight references such as file paths and loads data into context at runtime through tools. Choosing among these and combining them is a design decision the context engineer owns.

Who they work with

Context engineers work with product managers who define what an assistant should do, retrieval and data engineers who own the sources, security reviewers who decide what untrusted content may reach the model, and evaluation staff who build test sets. Their deliverables include context-assembly code, token budget specifications, memory and retention policies, tool output schemas, evaluation reports and incident write-ups that explain why an agent went wrong.

No license, degree or certification is required to work as a context engineer, and no professional body certifies the specialty. The usual starting point is software engineering. As a rough guide, people move into the role with a bachelor's degree in computer science, software engineering or a related field and around 3 to 5 years of building production software, including some time shipping applications on top of large language models. Backgrounds in search and information retrieval, data engineering or machine learning engineering also carry over, because each covers one piece of the job.

Technical skills

• Programming and model APIs. Fluency in Python or TypeScript and comfort with provider APIs, streaming responses, tool calling and structured output.
• Token economics. How tokenization works, how prompt caching changes cost, and how to divide a window among instructions, history, retrieved text and tool output.
• Retrieval literacy. Enough knowledge of embeddings, vector stores, hybrid search and reranking to judge what the retrieval layer returns, even when someone else builds it.
• Memory and state. Designing what an agent persists between sessions, how entries are keyed and retrieved, and when they are deleted.
• Agent protocols. Hands-on work with Model Context Protocol servers and clients, tool schemas and multi-agent handoffs.
• Evaluation. Test sets, automated graders and regression suites that catch a context change that quietly breaks answers.
• Security basics. Prompt injection, leakage of system prompts, and permission boundaries for tools.

Working habits

The job rewards people who read model traces the way a database engineer reads query plans: line by line, looking for the wasted or missing piece. Strong candidates write down their budget assumptions, keep old evaluation results for comparison, and resist stuffing the window just because a model's advertised limit is large. They also explain trade-offs to non-engineers, since some context bugs turn out to be policy questions (should the assistant remember this at all?) rather than code defects.

Credentials and learning

Certifications are optional. Engineers who work on one cloud platform sometimes add a credential such as AWS Certified Machine Learning Engineer Associate from Amazon Web Services or the Professional Machine Learning Engineer certification from Google Cloud, but neither covers context design directly. Practical learning comes from model vendors' engineering documentation, open-source agent frameworks, the Model Context Protocol specification and time spent debugging real agents.

Building a portfolio

Candidates without the title can show the skill directly: an agent that completes a long task without losing track of its goal, an evaluation harness with before-and-after results for a context change, or a published MCP server whose tool outputs are compact and well labeled. A short write-up explaining the budget decisions behind each project shows hiring managers the reasoning, not just the code.

The Bureau of Labor Statistics does not count context engineers. As context only, BLS expects the broader group of software developers, quality assurance analysts and testers, which held 1,905,400 jobs in 2025, to add 10 percent by 2035, a projection for the field context engineers come from rather than for the specialty.

How AI is affecting the work

BLS has been open about the uncertainty. In a 2025 Monthly Labor Review article on building AI into its projections, the agency wrote that the effects of AI proliferation on software developers are highly uncertain: AI is well suited for the occupation's tasks, yet productivity gains may lower prices and increase demand for software products. It added that AI itself may lead to increased demand for software developers, who may be needed to develop AI-based business solutions and maintain AI systems. Context engineering is part of maintaining AI systems in that sense: someone has to decide, request by request, what a model reads.

Analysts named the shift

Gartner put it bluntly in a July 2025 research note: "Context engineering is in, and prompt engineering is out." In an October 2025 article, the firm defined context engineering as designing and structuring the relevant data, workflows and environment so AI systems can understand intent and make better decisions. Because the label is young and BLS does not report it separately, the same work can sit under broader titles such as AI engineer or software engineer, so job seekers should read the duties in a posting rather than rely on the title.

Standards moved to neutral ground

Some of the plumbing context engineers use now sits under shared governance. On Dec. 9, 2025, Anthropic announced it was donating the Model Context Protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation, and MCP became a founding project; the protocol's blog said the move ensures vendor-neutral governance for its future. On Oct. 22, 2026, the Linux Foundation reported that the foundation had grown from three projects to 10 in its first year, adding Agent Skills, contributed by Anthropic, and Open Responses, contributed by OpenAI, among four new projects.

Security raises the stakes

Every passage, web page or tool result admitted to the window is a possible attack path. The OWASP Top 10 for LLM Applications 2025 lists prompt injection as LLM01 and describes indirect prompt injection, which occurs when an LLM accepts input from external sources such as websites or files. The same list includes system prompt leakage, vector and embedding weaknesses, and unbounded consumption, each tied to what goes into or comes out of a model's context. NIST's March 2025 taxonomy of adversarial machine learning traces many security vulnerabilities in LLM applications to the fact that data and instructions are not provided in separate channels. Designing for those risks is part of the job description, not an add-on.

Where the role leads

Context engineers can grow into staff or principal engineers who own an organization's agent platform, AI architects who set standards for how product teams assemble context, or managers of applied AI teams. Others move toward evaluation and AI quality leadership, or toward security work focused on agent permissions and injection defense. Employers include AI labs, cloud and developer-tool companies, software vendors adding agents to their products, and large enterprises building internal assistants over their own documents.

Dear Hiring Manager,

I am applying for the Context Engineer position on your applied AI team. For the past four years I have built backend services as a software engineer, and for the last two I have worked almost entirely on the assistant our support organization uses to answer customer questions from our product documentation and ticket history.

When I joined that project, the assistant answered short questions well and fell apart on long ones. Traces showed why: every turn carried the full conversation, a dozen retrieved passages and raw JSON from three internal tools, and the instructions that mattered were buried in the middle. I rebuilt the assembly step around an explicit token budget, moved tool responses into compact schemas that kept only the fields the model used, and added a compaction step that turns older turns into a short running summary of decisions and open questions. I also wrote a memory policy with our legal team that defines what the assistant may store about a customer and when it is deleted.

None of that would have stuck without evaluation. I built a regression suite from real escalated tickets, with graders that check whether the answer cites the right document and respects the customer's stated constraints. Every context change now runs against it before release, which turned debates about whether a change "felt better" into a quick review of results.

I would bring the same habits to your team: read the traces, write down the budget, test before shipping, and treat retrieved content as untrusted until it is labeled and screened. I would welcome the chance to discuss how your agents manage context today and where they lose the thread.

Sincerely, Jordan Avery