In autumn 2025, "context engineering" was the phrase much of the AI industry reached for. A year later the excitement has gone elsewhere, and the problem the term named is still where it was. The rest of this piece reads that year season by season, because what happened to the term tells you what the term was.
Autumn 2025: the term arrives with a promise
At the peak, "context engineering" carried a quiet promise: that agents fail because of what they are shown, and that a discipline of choosing what to show them would fix it. The promise was half right, and the half that was right is old. An agent answers from what it can see. If it cannot see which definition of revenue is the certified one, which customer record is the real one, or which version of a policy is current, it guesses, and a stronger model guesses more fluently.
A widely repeated example comes from Atlan: an agent told finance that Q4 revenue was $12 million when the real figure was $8.4 million, because it read revenue_recognized where it should have read revenue_net_of_returns. The model did not miscalculate. Nobody had told it which column carried the agreed meaning. Atlan sells data catalog tooling, so take the story as an illustration of a mechanism and not a measurement of how often it happens.
Through 2025 and into 2026: the surveys point at data
Across the same stretch the surveys kept saying the same unglamorous thing. Capgemini Research Institute found that trust in fully autonomous AI agents fell from 43% to 27% in a year, with 80% of organizations lacking mature AI infrastructure to support them (Capgemini, 2025). A March 2026 study by Cloudera and Harvard Business Review Analytic Services found that only 7% of enterprises say their data is completely ready for AI.
Both are survey results, and respondents define "ready" and "trust" for themselves. They are consistent with the mechanism above and do not prove it. The modest reading is that the bottleneck most people name is data, not model quality.
Summer 2026: attention turns toward failure
By summer 2026 attention was moving from how to build with models to what goes wrong with them.
Here is our reading of why the term faded. Look at what fixing the Atlan problem requires: one certified definition per metric, one canonical identifier per customer, a record of where each number came from, and rules about who may see what. Data teams already have names for these: metric definitions, master data management, lineage, access control. Context engineering is largely that discipline relabeled for a new consumer. The people with solid master data never needed the new word, and the people without it could not fix the problem with one. A term that serves neither group has a short shelf life, and "context engineering" is aging the way "prompt engineering" did.
What the trajectory implies
The vocabulary will fade and the work will not. Three things follow, and none of them needs the term.
First, a company running Odoo or ERPNext has already done part of this work, whether or not anyone planned it that way. The chart of accounts is a certified set of definitions. The item master and the partner table are canonical identifiers. Document status fields say which version is current, and role-based access already limits who sees what. ThinqHub implements both systems, so we know how much of "context" is already sitting in a well-run ERP. An agent that queries the ERP through a narrow, permissioned interface inherits those definitions; an agent pointed at a data lake export of the same tables inherits the column names and nothing else. The reverse also holds: if the ERP has duplicate customers, free-text fields where codes should be and three people using "closed" differently, no agent will repair that. It will quote it with confidence.
Second, some behavior belongs outside the model. A banking agent has to verify identity before it discusses a balance, and a reasoning model cannot guarantee that sequence on every run. Salesforce makes the same point in its 2026 agent trends piece. Put such rules in ordinary workflow code, where they are tested and cannot be argued out of by a clever input. A rule that lives only in a prompt is exactly what prompt injection goes after.
Third, context is not the connection layer. Protocols such as MCP, covered in our post on AI agent interoperability, let an agent reach a system. Context decides what it understands when it gets there.
A start that fits a small company: pick the two or three numbers your team argues about, such as recognized against booked revenue, or active customer against registered account. Write down the single definition and who owns it. Point any agent or ERP integration at that definition and make it return the source of each figure it quotes. Decide what each agent may read, instead of granting access to the whole estate.
This is the groundwork before an agentic AI deployment, and the order matters: data first, model choice after. Our approach begins with checking whether your data can support an agent at all. Get in touch to find your gaps before you build on them.
