In short: Context engineering is a real discipline, practised at the wrong altitude for a CTO. Since 2025 the industry has renamed the practitioner's skill twice, from prompt to context to harness engineering. Each rename tracks the constraint moving outward from the agent. None names who owns, funds and governs context across the organisation, which is where the constraint now sits.
How many times has the industry renamed this job?
On 28 July 2025, Gartner told AI leaders that context engineering was in and prompt engineering was out, and advised them to build context-aware architectures instead of polishing instructions. A month later, Cognizant announced it would deploy 1,000 context engineers within a year. When a services firm of that size hires a thousand people into a title, the discipline has a labour market.
Six months on, the name changed again. In February 2026, Mitchell Hashimoto described the habit of engineering the environment around an agent so that it never repeats a mistake. Days later, OpenAI published an account of a small Codex team building a product of roughly a million lines, across about 1,500 merged pull requests, with no hand-written code. It called the practice harness engineering. The figures are OpenAI's own report of an internal experiment, so read them as a signal of direction. By July, Martin Fowler was noting that a term nobody at his retreat had heard of in the spring now had a session of its own.
Three names in about four years. Two in twelve months.
When I wrote about the second Absorption Gap, I observed that the industry had renamed the discipline while leaving the CTO's job untouched. Since then the practitioner's job has been renamed once more, and the executive one is still waiting. I will call it the unnamed job. It is the subject of this piece.
What does each rename get right?
The case for the renames is strong, so start there. Chroma's context-rot study tested 18 frontier models and found every one lost accuracy as its context grew, some sliding from around 95% to 60 or 70% well before the window filled. Mei and colleagues surveyed more than 1,300 papers and treated context engineering as a discipline in its own right. Deciding what an agent sees is engineering work, and so is building the linters, tests and permission rules that surround its run.
The immediate interpretation writes itself: identify the new skill, then hire and train for it. It is a sensible move at the bench, and most leadership teams are somewhere along that path. Is it the move that decides whether AI pays off across the whole organisation?
Where is the constraint moving?
Read the three names as a sequence and a pattern appears. Prompt engineering located the constraint in wording. Context engineering moved it to information: what the model sees, how fresh it is, how well it is structured. Harness engineering moved it again, to the environment around the whole run, where tools, feedback loops and gates decide whether work is accepted.
This is Constraint Migration, the mechanism I use to describe the output side of AI adoption, observed from inside the agent. Relieve one constraint and it resurfaces at the next least scalable step. Each rename is the practitioner community correctly naming where the constraint went. Each also draws a slightly larger boundary around the agent, and every one of those boundaries stops at the agent.
Figure 1. Three renames, one boundary. Each name widens the circle around the agent; the organisational layer the constraint has moved into still has no name.
The next migration has already crossed that line. Context that compounds across use cases needs a semantic model of the business, a freshness guarantee, access rules and decision traces that outlive any single team's harness. Place the renamed skills on the AI Engineering Production System and they sit inside Build and part of Verify & Govern. The context supply feeding the agent workforce, and the governance overlay that spans every stage, appear in nobody's job title. That gap is the unnamed job.
Haven't we built a harness before?
The vocabulary is new; the mechanism is familiar. Over the last decade, many engineering organisations built exactly this kind of harness for people. At La Redoute, commit-to-production fell below ten minutes, deployments rose from 40 to 80 a day, and creating a new service went from days to minutes. Those gains came from two things: engineering context that every team could build on, meaning shared standards, templates and a common platform, and a harness of gates for code, test and deploy that let people ship safely at speed.
What made them compound was ownership. The harness was built once, run as a platform and an operating model, and shared by every team. Much of what the 2026 harness literature describes, from CI gates to test feedback to permissions that fail closed, is verification discipline that quality engineering spent those years maturing. Even Birgitta Böckeler's early writing on the subject suggests harness templates as a way to share guides and sensors across a larger organisation. Someone still has to own the template.
What do the renames leave unowned?
Three questions sit above every practitioner title, and each has a number attached.
Who owns context as an asset? In Redis's 2026 survey, 81% of organisations were still in the two earliest maturity stages, and a third said they were stitching AI infrastructure together from disconnected point solutions. Redis sells data infrastructure, so treat the exact split as directional. The pattern of improvised, per-project assembly matches what independent surveys report.
Who funds it? When context is rebuilt for each project, it is paid for as project expense and every new use case starts from zero. What happens to the economics when the tenth agent costs as much to feed as the first?
Who governs the fleet of harnesses? Mayfield's 2026 survey of 266 CXOs found 60% without a formal governance framework. In the Redis data, governance tooling was the most-cited barrier to production maturity, named by 37%.
Figure 2. The AI Engineering Production System, with the renamed skills in place. The practitioner disciplines cluster at Build and Verify; context supply and system-wide governance have no named owner.
One mechanism sits beneath all three questions. Organise a capability as a practitioner skill and each team reproduces it in its own way, which produces fragmentation by design. Compounding needs an owner above the teams, with a budget and a remit that spans them.
What should a CTO measure instead?
Context engineers hired, harnesses deployed and agents in production are activity metrics, the input-side cousins of pull-request counts. They confirm that supply is growing. Do they tell you anything about value?
The measure I keep returning to is validated business value per unit of human intervention, with one compounding signal beside it: how much of the context built for one use case is reused by the next. Only 42% of organisations in the Redis survey say they can measure production readiness accurately. A reuse rate near zero is the clearest evidence that the unnamed job is still vacant.
The org-chart test
Take your most important agent in or near production and name one accountable person for each of three things: the context it runs on, the harness policy it runs under, and its readiness for production. Write the names down.
Three different team leads means the job is split. "The team that built it" means the job is unnamed. One person with a budget and a remit across teams means you have started building the organisation the renames keep pointing towards. Expect the second answer far more often than the third.
The question to take into the next leadership meeting
The practitioner community will find the next name within a year; the pace of the last two renames makes that close to certain. Each name will describe the bench accurately. The executive question sits one altitude up. Will you design the operating model that owns context before the next rename arrives, or reorganise around it afterwards?
A new title for the skill will never fill the unnamed job. An owner will.
This piece completes an opening sequence with The Absorption Gap and The Second Absorption Gap.
FAQ
What is the difference between prompt, context and harness engineering? Prompt engineering shapes the wording of an instruction. Context engineering decides what information a model sees at each step, and how fresh and well structured it is. Harness engineering designs the environment around the whole run: the tools, feedback loops and gates that decide whether an agent's work is accepted. All three are practitioner disciplines, and each widens the boundary around a single agent.
Should we hire context engineers? If agents are in production, the skill is real and worth having. Hired team by team, though, it reproduces context separately for every project, so nothing compounds. Decide first who owns the context system across the organisation, then hire into that structure.
Who should own context in an enterprise? A named owner with a budget and a cross-team remit, in the way a platform or data capability is owned. The role covers the semantic model of the business, freshness, access rules and the decision traces every agent draws on. Where it sits on the org chart matters less than the fact that it exists.
Is harness engineering just testing renamed? Partly. Much of a harness, including CI gates, test feedback and permissions that fail closed, is verification discipline that quality engineering matured over the last decade. Newer elements such as agent memory, planning artefacts and sub-agent isolation are genuinely additional. The organisational lesson carries over intact: the gains arrive when the harness is owned once and shared by every team.
How does this relate to the Absorption Gap? The Absorption Gap is the distance between the supply AI adds and the organisation's capacity to absorb it. On the input side, agents arrive faster than their context can be supplied and governed. The unnamed job is the absorption capacity that has to scale to close that gap, and practitioner renames do not create it.
Read further
The thesis in full: Redesigning engineering production for the agentic era
The model behind this piece: the AI Engineering Production System
The concept page: the Absorption Gap
The lived proof of the pattern: I've Seen This Bottleneck Before
The output-side original: The Absorption Gap
The governance front: The Second Absorption Gap
Verification as a capability: Quality Engineering
Sources
Faros AI, AI Engineering Report 2026: The Acceleration Whiplash (telemetry from ~22,000 developers, 4,000 teams). faros.ai/research
Sonar, State of Code Developer Survey (January 2026, 1,100+ developers). sonarsource.com
CircleCI, 2026 State of Software Delivery (February 2026, 28M+ workflows) and Q2 2026 State of Software Delivery (July 2026). circleci.com/blog
New Relic, 2026 State of AI Coding Report.
GitClear, AI Copilot Code Quality (2025; 211M changed lines, 2020–2024). gitclear.com
Redis, State of Context Engineering 2026.
E. M. Goldratt, The Goal (1984); TOC Institute, The Five Focusing Steps. tocinstitute.org.