The Context Engineer's First 90 Days

Most people who become context engineers arrive from data engineering, analytics, or platform work. They are handed a vague mandate: make the AI assistant useful. There is rarely a job description, rarely a predecessor, and almost never a definition of done. That ambiguity is the first trap. Without a plan, new context engineers drift towards the most visible work, which is usually swapping models or rewriting prompts, and away from the work that actually moves answer quality.

The thesis of this playbook is simple. Your first quarter is a conversion project. You are converting institutional knowledge, the definitions, exceptions, permissions, and habits that live in people's heads and scattered documents, into infrastructure that an agent can use and that a team can audit. That is the gap Chapter 1 names as the real bottleneck: not what the model knows, but what the organisation knows and has never written down.

The plan below runs in three phases of roughly thirty days each: Map, Build, Govern. Each phase ends with a deliverable you can show. The timings are guidance, not law; a smaller company may compress them and a regulated enterprise may stretch them. The order matters more than the dates.

Resist the urge to open the retrieval pipeline on day one. Open a notebook instead. Sit with the three or four teams whose questions the assistant is meant to answer and collect the words they use: revenue, active customer, churn, region, priority account. For each word, ask two questions. What does it mean to you? Where would I find the official version?

You will discover that the same word means different things in different rooms. Finance counts revenue net of refunds; sales counts bookings. Support calls a customer active if they opened a ticket; product calls them active if they logged in. Every one of these conflicts is a future wrong answer, and the model cannot resolve them because the organisation has not. Chapter 4 explains why business meaning, not raw data, is what grounds an agent.

By day ten, produce a one-page vocabulary map: the twenty terms that matter most, the competing definitions, the owner of each, and the source of truth. This page will become the seed of your semantic registry, and it is often the first artefact a senior stakeholder has ever seen that shows the disagreement plainly.

Now open the pipeline. Pull a sample of one hundred real questions from logs or from users, run them, and read every answer with the source passages beside it. You are looking for patterns, not individual bugs: stale documents outranking current ones, chunks that cut a table in half, permission leaks, and questions that should have been refused.

Record each failure in a simple register with four fields: the question, what went wrong, which layer caused it (source, retrieval, context assembly, or model), and the business cost if it reached a customer. Most teams find that the majority of failures sit in retrieval and source quality, not in the model. Chapter 35 covers the retrieval mechanics you will need to diagnose them.

The register is your most persuasive document. It turns a vague feeling that the assistant is unreliable into a ranked list of causes with owners. End the month by presenting the vocabulary map and the top ten failures to your sponsor. That meeting earns you the room to build.

Phase two begins by turning the vocabulary map into something machines can read. A semantic registry does not need a new product; a versioned table or a governed set of metric definitions is enough to start. Each entry carries the term, the agreed definition, the owner, the source table, the valid date range, and the access policy.

Then connect the registry to the agent. When a question mentions a registered term, the definition and its source travel into the context alongside retrieved passages. This one change often fixes a surprising share of the failure register, because the model stops guessing which revenue you meant. Chapter 10 describes this kind of institutional memory, and Chapter 11 explains why it must be treated as a living layer that changes as the business changes.

With meaning in place, improve retrieval against the failure register. The usual sequence is: clean or retire stale sources, fix chunking on structured documents, add keyword search alongside vector search, and add a reranking step. Change one thing at a time, so you know what helped.

You can only know what helped if you can measure it. Build a golden evaluation set of fifty to one hundred questions drawn from real use, each with the expected answer, the acceptable sources, and a note on whether the agent should refuse. Include the hard cases from your register, not just the easy wins. Chapter 26 treats evaluation as the dashboard of an AI system; the golden set is the first gauge on that dashboard.

Run the set before and after every change and keep the scores in a shared sheet. By day sixty you should be able to say, in one sentence, how much more often the assistant is right than it was on day thirty, and why.

Phase three is about trust. Review what the agent can read and what it can do. Retrieval must respect the same permissions as the source systems; an agent that summarises a document a user could not open is a security incident waiting for a date. Any action that writes, sends, or pays should have an approval gate or a circuit breaker, as Chapter 15 describes.

Write a short incident runbook: how to stop the agent, how to freeze a session for review, who gets paged, and how to roll back a bad source or definition. You hope never to use it. Having it is what lets security and legal say yes to the next expansion.

Before you hand anything over, put numbers on it. Track cost per answered question, median and slow-tail latency, and the share of tokens spent on context the answer never used. Trimming unused context and caching stable prefixes often cuts cost noticeably without touching quality; Chapter 36 explains compaction and token budgets, and Chapter 29 covers the wider cost picture.

Add a small set of context-health measures: how many registry terms are past their review date, how many sources have not refreshed on schedule, and the golden-set score over time. These are the leading indicators that tell you answers are about to degrade before users notice.

At day ninety you should be able to put five things on the table: a semantic registry with owners, a golden evaluation suite with a score history, measurably better retrieval, a cost and latency dashboard, and an incident runbook. Together they are proof that context is now infrastructure, not folklore.

Three short scripts help along the way. To a domain expert: "I am not asking you to learn AI. I am asking you to tell me what this word means when you use it, so the assistant stops getting it wrong." To a sponsor: "Here are the ten reasons answers fail, ranked by cost. I will fix the top three this month and show you the score." To security: "The agent can only see what the user can see, and here is the switch that stops it."

Model shopping: switching providers every few weeks in the hope that a smarter model will hide missing context. It will not, as Chapter 8 argues. Prompt polishing: tuning wording endlessly while the sources stay stale. Boiling the ocean: indexing every document in the company before defining a single term. And demo-driven development: optimising for the impressive five questions in the steering meeting rather than the hundred real ones in the logs.

The common thread is measuring nothing. If you cannot show a before and after score, you are relying on impressions, and impressions are what got the assistant into trouble. For the longer arc of the role, read The Context Engineer Job Description, The 30-Day Path from Data Engineer to Context Engineer, and The Context Engineer's Promotion Packet.