March 2026. One of our tests on an internal version of BP — the business plan assistant launching in the coming months. We ask the agent: "Calculate the first-year DSCR of company XYZ's plan."
The agent answers: "The DSCR for the first year is 1.42, in line with sector benchmarks."
Perfectly formulated answer. Professional tone. Credible number.
Wrong number.
The actual one, calculated by hand, was 0.87. The plan had a structural debt-service coverage problem. A DSCR below 1 means the company, at regime, doesn't generate enough cash to pay interest and capital portions of financing. It's exactly the type of anomaly an expert consultant sees in ten seconds, and that a well-made business plan should flag with a big exclamation mark.
The agent had missed it. Not because the prompt was poorly written. It was excellent. It had missed it because the context we'd passed it didn't include updated cash data. There was a three-day-old version, frozen in cache, perfectly plausible and completely out of sync.
This is the problem we want to tell you about today. For two years the industry — us included — talked about prompt engineering as the central discipline of corporate AI. Building real products, we understood it's the right discipline solving the wrong problem.
The real one is called context engineering. And in 2026 it's what separates AI projects that work from those that work great in demo and badly in production.
The difference in two lines
Prompt engineering: how you formulate the question to the model.
Context engineering: what the model knows at the exact moment it answers the question.
Put this way it sounds like a subtlety. It isn't.
Think of it like a lawyer. You can write a perfect legal request, with all the technicalities, the ritual formulas, the right tone (perfect prompt). But if on the day the lawyer reads it they're still up-to-date with 2018 law, they'll give you an obsolete opinion. What counts isn't just how you asked them. It's what they have in mind when they prepare it for you.
The same applies to an LLM in production. The prompt is the request. The context — the documents it has "in view", the data you pass it, the tools it can call — is its "head" at that moment.
The five real context problems
When you say "context" to a room of technicians in 2024, they mean "the tokens preceding in the prompt". When you say it to a room of technicians in 2026, they mean five things together:
1. What you put in the context. Which pieces of your documentation, your data, your products, the model sees at that moment. Not everything — LLMs have a limited working memory (the context window), and too much context degrades the quality of the response like too many slides degrade a presentation.
2. Where you get it from. Your database, vector database (see the piece on Embeddings last week), real-time API, local cache, file on disk, internet (risky). Each source has its own SLA, its own cost, its own latency.
3. How fresh it is. When was it last updated? Are we talking about this morning's data or three weeks ago? In an agent that has to tell you if an event has available spots (Tuken, for example), a thirty-second difference is already serious.
4. Who has permission to see it. If the agent is talking to the salesperson, can it see margins? If it's talking to the customer, no. Context engineering is also how the system filters context based on who's asking.
5. What it does when it's missing. If the information isn't there, should the model say "I don't know" or try to extrapolate? If it extrapolates, we have the hallucination everyone complains about. If it says "I don't know", we have an honest but frustrating agent. The right answer is almost always in the middle, and that's a product choice, not a technical one.
Companies that ask themselves these five questions before putting an agent into production have agents that work. Those that ignore them have beautiful demos and disasters three weeks after go-live.
Three things we learned doing it
In order of increasing discomfort.
First thing. The bulk of development time for a modern AI agent isn't written in the prompt. It's written in the context pipelines: the code that decides what to feed the model, when, in what order, with what freshness. It's 70-80% of the real technical work. The prompt — that string you're seeing in your mind — is 5%.
Second thing. Debugging an agent that's wrong is almost always a context problem, not a prompt problem. When an agent "hallucinates", in 90% of cases it's not because the model is "off" — it's because you passed it an incomplete, old, or ambiguous context. Changing the prompt doesn't fix it. Changing what the model sees does.
Third thing (the worst). Context engineering is the part of the product hardest to communicate to the customer. If you sell AI to a company, the prompt is what they understand right away. The context is invisible. And when you explain that "your investment is to build the context pipeline, not to write longer prompts", many nod and then ask you "but concretely what does it do?" Answer: it makes the difference between "this AI answers randomly" and "this AI really serves me". But it's a harder sale.
What changes for those buying AI in 2026
If you're a company evaluating an AI vendor in 2026, your filter must change.
The questions from 2024 were: which model do you use? How many tokens per call? How long does integration take? Do you have experience in our sector?
The questions from 2026 are different:
- Where do you take context from, and with what update strategy? (If the answer is "we load your documents once", run.)
- How do you handle permissions on the context? (If the answer is "we'll see later", run.)
- What does the agent do when context is missing or ambiguous? (If the answer is "the model figures it out", run fast.)
- Do you have context observability pipelines? (Meaning: when a user complains about a wrong answer, can you reconstruct what context the model saw at that moment? If you can't, you can't correct. If you can't correct, you're paying yourself an illusion of control.)
Four questions. If the vendor hesitates on one, take two steps back. If they hesitate on two, thank them and look for someone else.
What we're building inside the house
For honesty's sake: we're the first to not have all the answers. On BP, the context pipeline is the thing we've rewritten three times already. Initially the anagrafic documents were loaded once and that was it. Result: a plan that didn't update cash data, and the wrong DSCR mentioned above. Now context regenerates with every critical interaction, has an explicit freshness system, and the agent can tell you when the data it's using to answer was updated. A level of transparency that, last month, we started calling "data provenance" — old term in the data world, new term in the AI agents world.
On Tuken, the problem is different: context changes in real time (an event fills up, a package sells out). There we had to invent a mechanism where the model knows "this information is only valid for the next 30 seconds". Stuff that in the classic SaaS world we'd call time-to-live of a cache. In AI context it's still new land.
On Blogger — the AI-native publishing platform in private beta — the problem is even different: the context that matters is the client's editorial line and past articles. There we're experimenting with "narrative" context engineering, where the agent understands the tone of the client not because a manual describes it, but because it sees the latest articles and reads them as a new editor would.
Three products, three completely different context engineering approaches. Same lesson: the prompt is worth little; the context is worth everything.
The operational rule
Distilled into one line: don't spend the AI budget on longer prompts. Spend it on context pipelines.
More precisely: the prompt must be clear and well-structured — but once written, optimizing beyond that point gives diminishing returns. The real ROI of 2026 is building a system that decides well what the model sees at response time. That system is the real product.
Those who understand it now will build the valuable AI products of the next three years. Those who continue to dance around it with richer prompts will build demos that impress internal committees and collapse in production.
They're two different paths. Choose one consciously.
Monday, June 15 we leave the technical side and return to marketing: Cookieless came anyway, and nobody's talking about it. Google changed its mind twice. The cookies are formally still there. Yet the cookieless world has arrived through the back door.
Have an AI agent in production (or in quote) and not sure context engineering is up to the task? Under artificial intelligence for business we do operational audits of AI pipelines. Half a day, operational output, no slides. Let's talk.