The Context Engineer's Promotion Packet

Two years ago, connecting a model to an internal API was enough to earn a shout-out at the all-hands. Today most enterprises have dozens of such prototypes, and leadership trusts almost none of them in front of a customer. The novelty has gone. What remains scarce is someone who can make an agent dependable.

That shift has reached the promotion committee before it has reached most job ladders. A staff engineer reviewing your case does not ask whether you built an agent. They ask what changed for the business, how you know, and what would have happened without you. 'We shipped a support copilot' is a sentence. 'Our support copilot resolves 41 percent of tickets with no human edit, at 18 cents per correct resolution, and has not taken an unapproved write action in six months' is evidence.

The difference between those two sentences is not talent. It is whether the engineer built the instruments that produce the second one. This essay is about those instruments. It extends the argument in The Agent's Manager Is the New Job: if your job is to manage agents, your promotion case is the record of how well they were managed.

The evaluation harness is the single most persuasive document an AI engineer can produce, because it turns 'it seems to work' into a number that can be tracked over time. It is a versioned set of representative tasks, each with an expected outcome and a scoring rule, re-run on every change to the prompt, the retrieval, the tools, or the model.

What makes it promotion evidence is not its existence but its history. A committee wants to see the baseline, the regressions it caught before users did, and the model upgrade it allowed you to approve or reject in a day rather than a month. A single line such as 'blocked a model upgrade that dropped refund accuracy from 94 to 81 percent' carries more weight than a page of architecture diagrams.

Build the set with the business, not alone. A product manager and a domain analyst who helped write the cases become witnesses to your impact. Chapter 21 explains how to choose between quality, speed, and cost once you can measure them, and Evals Are the Dashboards makes the wider case for treating the harness as an operating instrument.

Most agent failures in production are not reasoning failures. They are context failures: the agent was handed a deprecated policy, the wrong customer's notes, or forty pages of near-duplicates. The engineer who fixes this has done some of the highest-leverage work in the system, and almost nobody notices unless it is written down.

The retrieval contract is that written record. For each agent it states which sources may be retrieved, who owns them, how freshness is guaranteed, how deprecated documents are excluded, and how retrieval quality is measured — recall at k, citation accuracy, and the share of answers grounded in an approved source. Chapter 35 covers the mechanics of chunking, hybrid search, and reranking that the contract governs.

The career value lies in what the contract preserves. When you capture why a source is trusted or excluded, you are building the institutional memory described in Chapter 10. That memory outlives the model, the vendor, and frequently the team. Being its author is a durable kind of seniority.

Finance does not care how many tokens you used. Finance cares whether the work was worth paying for. The metric that bridges the two is cost per correct outcome: total spend on a workflow — model calls, retrieval, retries, and human review — divided by the number of outcomes that were actually right.

This metric is unusually good for careers because it rewards the work that makes systems better rather than merely bigger. Routing easy tasks to a smaller model, compacting history so prompts stop growing, caching stable context, and cutting retries all show up directly. Chapter 18 describes the hidden costs that the scorecard exposes, and Chapter 36 shows how compaction and token budgets bring them down.

Present it as a trend, not a snapshot. 'Cost per correct invoice match fell from 42 cents to 11 cents over two quarters while accuracy rose four points' is the sentence an engineering director repeats to a CFO. When someone else repeats your number in a meeting you are not in, your promotion case is already being made. Every Agent Needs a P&L gives the full accounting model.

The fourth artifact proves a negative: that the agent cannot do the damage everyone is quietly worried about. It lists every action the agent can take, the limits on size and rate, which actions are reversible, which require human approval, and which identity the agent acts under.

Security and risk teams are the most sceptical audience in any enterprise, and the most influential in a promotion discussion for platform work. An engineer who can show that the agent runs under a scoped, short-lived identity, that writes above a threshold need approval, and that every action is logged has turned a risk conversation into a trust conversation. Chapter 14 moves the frame from access control to action control, and Chapter 15 covers approvals and audit trails.

The gate also documents the human role. Chapter 17 argues that a human in the loop still matters; the gate says exactly where, and why. Pair it with The Blast Radius and Your Agent Needs an Identity, Not a Password for the operational detail.

The artifacts are the evidence. The metrics are the summary a busy reader takes away. Keep the list to four, and report each with a baseline, a current value, and a one-line explanation of what you did to move it.

**Unassisted completion rate.** The share of tasks the agent completes correctly with no human edit. It is the clearest signal of real autonomy, and it only counts when the eval harness confirms correctness.

**Cost per correct outcome.** From the scorecard above, reported as a trend over at least two quarters.

**Context freshness.** The time between a business change — a renamed product, a new policy — and the moment the agent reflects it. Hours is excellent; weeks is a liability.

**Portability readiness.** How long it would take to move the workload to a second model or vendor, tested rather than estimated. Chapter 22 explains why lock-in is a strategic risk, and The Exit Test describes the drill. An engineer who has made this number small has given the company leverage in every future negotiation.

None of this requires a new title before you begin. It requires one workflow, one sponsor, and a quarter. Chapter 29 sets out the longer career roadmap; this is the first lap of it.

**Days 1 to 30: establish the baseline.** Pick the agent that matters most to a business owner. Write fifty evaluation cases with that owner. Measure accuracy, cost per correct outcome, and the list of actions the agent can take today. Write it all down, including the uncomfortable parts. The baseline is the most important document in your packet, because every later claim is measured against it.

**Days 31 to 60: install the gates.** Write the retrieval contract and exclude deprecated sources. Add action limits and approval rules. Introduce compaction or routing where the scorecard shows waste. Re-run the harness after every change and keep the log.

**Days 61 to 90: make it repeatable.** Run a portability drill against a second model. Publish a one-page dashboard with the four metrics. Then apply the same pattern to a second agent. The second one goes faster because the definitions and contracts already exist, and that speed-up is itself evidence: you have built a system, not a project. Chapter 31 describes the same compounding at the level of a first context layer.

Promotion documents fail when they describe activity. They succeed when they describe changes in the business with evidence attached. For each artifact, write three sentences: the situation before, what you built, and the measured result. Link the artifact itself so a reviewer can check it.

Name the people who used your work. The analyst who trusts the agent's numbers, the risk lead who signed off the gate, the finance partner who now quotes your scorecard. Senior roles are defined by influence beyond your own team, and these names are that influence made visible.

Finally, show judgement. Include one decision where you chose not to ship, not to upgrade, or not to automate, and the evidence behind it. Chapter 27 argues that judgement will matter more than any tool; a documented decision to hold back is the clearest proof that you have it.

The four artifacts map closely onto what the industry is beginning to certify. Retrieval design, memory, tool governance, compaction, and multi-agent coordination are the domains of the Databricks Context Engineer Associate exam, and the practice exam is a fast way to find the gaps in your own packet before a reviewer does.

A certification will not get you promoted on its own. A packet with four artifacts and four improving metrics will, and the certification makes the vocabulary on that packet familiar to the people reading it.

The work of context engineering is mostly invisible when it goes well. The packet is how you make it visible. Start the baseline this week.