Key Takeaways
- Chatbots and agents that let customers down tend to have a knowledge problem. Nobody gave them the facts about how your business runs.
- A model answers with whatever it’s been handed for that one reply, whether that’s your refund policy or a customer’s order history.
- Wording a request well still matters. Gartner’s July 2025 note told tech leaders to give context priority over prompts.
- Stuffing in extra pages can backfire. Chroma put 18 well-known models through its tests, and their answers slipped the more text they had to read.
- When customers trip up a pilot that did fine in the boardroom, check its inputs first. A pricier model can wait until you know what it’s reading.
Context engineering is the prep work that decides which facts an AI model has in hand for each question. Your refund rules might go in, along with an order the customer mentioned earlier. A pilot handing out confident wrong answers is usually working from gaps or old files. Fill those gaps and it has a real shot at production.
The money already spent makes this hard to ignore. MIT’s Project NANDA studied enterprise generative AI from January to June 2025. It found that 95% of organizations in its research saw no measurable return. That’s after companies had put $30 billion to $40 billion into the technology. The authors traced a big share of that to software that forgot context between uses and never improved from feedback. Your board probably asks every quarter when the pilot will start earning its keep. The trouble tends to hide in a handful of places, and once you know them, they’re not hard to check.
Table of Contents
- What’s Context Engineering Once You Strip Away the Buzzwords?
- What Happens to AI Pilots Once Real Customers Show Up?
- How Is Context Engineering Different From Prompt Engineering?
- What’s Sitting in the Context Window When a Model Answers?
- Wouldn’t a Larger Context Window Solve This?
- What Does Bad Context Look Like in a Live Product?
- Where Do You Start With Context Engineering on an AI Project?
- Are There Times When Prompt Writing Is All You Need?
- What Should You Ask an AI Development Partner Before Signing?
- Why Work With iTechnolabs on Context-Aware AI Development?
- Conclusion
- FAQs
What’s Context Engineering Once You Strip Away the Buzzwords?
Before your chatbot answers anyone, the system hands it a quick briefing. Whoever decides what’s in that briefing is doing context engineering.
Say you hire someone brilliant this week. They still won’t know your refund rules on day one, or which system has this month’s price list. Nobody would let them answer customers until someone had walked them through the basics. A language model needs that same briefing, and it needs a fresh one every time it replies.
Gartner’s explainer says the point of context engineering is to give these systems enough awareness of their situation to respond with relevance and precision. Anthropic, the company behind Claude, frames it more tightly. Its engineers describe the goal as finding the “smallest possible set of high-signal tokens” that make the right outcome most likely.
Tokens are the bits of text a model reads, usually a few letters or part of a word. Anthropic picked “smallest” for a reason. Each extra paragraph thins out the model’s focus a little, so it’s worth cutting anything a reader wouldn’t miss.
What Happens to AI Pilots Once Real Customers Show Up?
Demo questions are usually chosen ahead of time by someone who knows what the bot can answer. Customers don’t ask that way, and the bot often lacks the company know-how to keep up.
Only 5% of the custom enterprise tools in the NANDA research ever reached production. When the authors dug into why, model quality wasn’t high on the list. They kept running into brittle workflows and software that couldn’t learn from context. The report calls itself preliminary and keeps its sample anonymous. So read the 95% figure as a warning about how projects are run.
Take a support bot that’s been loaded with your help center articles. It looks great in the pilot. Then a customer asks about an order placed under last year’s pricing. The bot can’t see the order and has no idea the price list changed. So it makes up an answer and delivers it with total confidence.
Nobody on the pilot team asked that question, which is why nobody caught it. Swapping in a newer model won’t help either, because the newer one can’t see the order.

How Is Context Engineering Different From Prompt Engineering?
Careful wording on a request still helps. But wording is only a small part of what shapes the answer now.
When chat tools first took off, most of the advice out there was about phrasing. That held up as long as the request carried every fact the model needed. Once a tool had to pull live records or update your CRM, no amount of rewording could make up for what it couldn’t see.
In July 2025, Gartner sent tech leaders a short research note with a blunt headline saying context engineering was in and prompt engineering was out. It told them to start building systems that feed live business data to the model. Anthropic takes a softer line in its guide to context engineering for agents. Its team sees context work as the natural next step after prompt writing, with the prompt still part of the mix.
Thoughtworks noticed the same thing. In April 2026, its Technology Radar moved context engineering into the Adopt ring and described it as a basic part of how these systems should be designed.
| Prompt engineering | Context engineering | |
| The question it asks | How should I word this? | What does the model need in front of it right now? |
| Scope | One request | Every request across a session or workflow |
| Where facts come from | Typed in by a person | Pulled from documents, databases, past chats and tools |
| Good fit for | Summarizing a file you pasted in | Support bots, sales assistants and agents that act in your systems |
| What fixing it looks like | Rewrite the request | Change what gets retrieved, stored or blocked |
What’s Sitting in the Context Window When a Model Answers?
A customer’s question takes up a few lines. Your system piles plenty more on top, and the whole lot has to squeeze into a space with a hard size limit.
- Every request opens with house rules that stay the same from one chat to the next. A cap on discounts, say 10% unless a manager signs off, would live here.
- Then come the definitions your own teams don’t agree on. Returns are a good example. If your UK store gives shoppers 30 days and the US site gives 14, write that down, or the model ends up picking one for you.
- Search results get added too. The system digs through your files for passages that match the question and slips them in. People call this RAG (retrieval-augmented generation).
- Memory saves people from repeating themselves. Because earlier messages and notes from past visits are kept, a customer types their order number once and that’s it.
- Tool results arrive when an agent looks up stock or books a slot. Each result becomes fresh context for its next move.
- Permissions decide whose data can appear at all. A sales rep and a finance manager shouldn’t see the same records.
Everything above gets packed into the context window. Think of it as the model’s short-term memory for a single reply, and context engineering is the call on what makes the cut.
Wouldn’t a Larger Context Window Solve This?
Models now accept very long inputs, but they don’t read all of it equally well. Past a certain point, more text means worse answers.
It’s tempting to load the whole shared drive and let the model sort it out. Some models will take hundreds of pages in one go, so why not? The answer is something researchers call context rot.
Chroma ran a context rot study in July 2025 that put 18 leading models through the same tests, GPT-4.1 and Gemini 2.5 among them. The longer the input, the worse they did, even on easy jobs. Accuracy fell fastest when the question was worded differently from the passage holding the answer. A single passage that looked right but wasn’t could throw some models off.
Chroma sells retrieval software, so it has a stake in that result. A separate team from LMU Munich and Adobe Research saw accuracy slide the same way on a benchmark they built themselves.
So when you plan your own build, aim for a short briefing picked with care. Piling on extra pages rarely helps. Anthropic’s own coding tool works this way. It opens each file at the point a task calls for it, so the model only reads what’s relevant right then.
What Does Bad Context Look Like in a Live Product?
You won’t get an error message. You’ll get symptoms, and each one traces back to a gap in what the model could see.
It Sounds Sure of Itself and Gets It Wrong
The fact it needed wasn’t in front of it, so it filled the hole with something plausible. Picture a sales assistant quoting a discount tier you retired last spring. Customers believe it because it sounds certain.
Ask on Monday, Hear Something Else on Tuesday
A customer asks about their plan on Monday and gets one answer. On Tuesday the same question gets a different one. The usual culprit is two of your own records telling different stories. Say finance counts someone as active after a second order, while sales counts anyone who’s signed up. Whichever file the search hits first is the one the model believes.
Customers Have to Start From Scratch
A shopper explains the problem, gets handed to the next step and has to explain it all again. That’s a memory gap. Nothing from the earlier exchange was carried forward.
Old Policies Keep Showing Up
Someone updated the returns policy in March. The old PDF never left the search index, though, so the bot still quotes it. Stale sources are easy to miss because the answer reads perfectly well.
Someone Sees Data They Shouldn’t
This is the expensive one. If access rules aren’t checked before retrieval, a junior employee can pull up salary bands or another client’s contract. If you work in healthcare or finance, a slip like that can put you in front of a regulator.

Where Do You Start With Context Engineering on an AI Project?
There’s an order to this, and most of the early steps happen in meetings with your own people. Code comes later.
Step 1: Write Down What the System Decides
Make a plain list of the calls it’ll be making. Approving a refund is one. Sending a ticket to billing or support is another. For each item, ask what your most careful staff member checks before saying yes. Those answers become your context spec, and they’ll keep the project from wandering.
Step 2: Get the Unwritten Rules Out of People’s Heads
Your CRM and wiki will cover some of it. The rest usually sits with whoever’s been around longest, like the ops lead who knows which clients get special payment terms. Have that person jot the rules down in normal sentences, the kind of handover note they’d leave before a holiday. An engineer can shape it into data afterwards.
Step 3: Settle Access Before Anything Gets Connected
A model should only pull up what the person asking is cleared to see, and that needs deciding before the first database is wired in. Privacy law has a say as well. PIPEDA covers personal data on Canadians, and HIPAA covers US health records.
Step 4: Feed It Facts at the Moment They’re Needed
Loading everything upfront tends to muddy the answers. Give the system a short index of what’s out there and let it pull details step by step. When a conversation drags on, have it squash the older messages into a summary so the customer’s latest question gets proper attention.
Step 5: Throw Real Questions at It
Go back through last quarter’s support tickets and chat transcripts, messy spelling and all. And don’t skip the awkward ones your best rep groans about. Whenever an answer misses, find the passage that sent it the wrong way.
Step 6: Keep an Eye on It After Launch
Your prices and policies won’t sit still once you’re live, so every source needs a named owner and a date for its next review. Whenever a new version of a document is published, pull the old copy from the search index the same day.
This needs one senior person keeping the teams in step. If that seat’s empty, our fractional CTO services can fill it until you hire.
Are There Times When Prompt Writing Is All You Need?
Yes, plenty. When the request already contains everything the model needs, sharp wording gets you there.
Asking for a summary of a report you’ve pasted in is a good example. So is having a page of copy rewritten in your house style. Everything the model needs is on the screen in front of it.
Things change when the tool has to fetch records or take action in another system. You’re building a product at that point, and what the model reads deserves the same engineering care as your screens and database. Bolting retrieval and memory onto a simple task only adds cost and gives things more ways to break.
What Should You Ask an AI Development Partner Before Signing?
Plenty of sales decks open with the model the vendor plans to use. Push past that with these questions, and notice who answers in detail.
- Which of our systems will feed the model, and who chooses what it sees on each request?
- Say a junior rep asks about a client’s contract. What keeps the model from showing it?
- Our CRM says one thing and our billing tool says another. Which wins?
- Will you test on a batch of our own customer messages before launch?
- When our prices change, who updates what the model reads, and how fast does that happen?
- What number do you track to know answers are accurate after go-live?
- If the bot gets something wrong, can you trace it back to the exact passage behind it?
The ones worth hiring answer with specifics and can point to projects they’ve shipped. If the conversation keeps drifting back to whichever model came out last month, look elsewhere.
Why Work With iTechnolabs on Context-Aware AI Development?
Our teams set up what the model reads as part of the build itself. We’re also independently certified on how we handle the data it touches.
Whatever feeds the model will include some of your most private records. ISO 27001:2013 is the certification that covers how we protect information like that, and ISO 9001:2015 covers our quality management.
So far we’ve shipped 500+ apps, with 50,000+ end users between them. More than 300 developers work across our offices in Markham, Calgary, Ottawa and Sheridan, Wyoming. Public sector buyers in Canada can also work with us through the Government of Canada Procurement Supply Arrangement SA CW2395301.
As an AI development company, we build RAG pipelines, agents and LLM integrations that connect to the systems you already run. Teams adding model-driven features to an existing product can start with our generative AI development services. When the tricky part is wiring into an old CRM or ERP, our custom software development services team handles that side.
Conclusion
Think back to the last time your pilot gave a customer a strange answer. Odds are the model itself was fine. The record it needed was out of reach, or the policy it quoted had been replaced months earlier. Upgrade to a newer model and those blind spots come along for the ride, with smoother wording.
Closing them is what context engineering is for. You map the decisions and find the facts each one depends on. Then you lock down who can see what and keep every source current. That takes longer than swapping models. It’s also the work behind the small group of projects that reach production. The MIT team linked the stalled ones to tools that lose track of context.
Not sure where your own pilot stands? Pull twenty real requests and look at exactly what the model was given for each one. Patterns show up fast, and they’ll tell you whether a cleanup will do or you’re looking at a rebuild. When you want rough numbers, you can estimate your AI project cost on your own first.

FAQs
Is RAG the Same Thing as Context Engineering?
RAG, short for retrieval-augmented generation, is one piece of it. The system looks through your documents and hands the model the passages that fit the question best. Context engineering also covers instructions, memory, tool results, permissions and keeping sources up to date. A project can use RAG and still fail if those other pieces are missing.
Does Context Engineering Replace Prompt Engineering?
It absorbs it. Clear instructions still matter, and they’re one of the things a context engineer manages. Anthropic describes the shift as a natural progression from prompt writing. Where prompt work covers a single request, context engineering looks after everything the model sees across a session or workflow.
What Is Context Rot?
Context rot is the drop in accuracy a language model shows as its input grows longer. Chroma’s July 2025 study tested 18 leading models and saw it even on simple tasks. It’s why stuffing whole document libraries into a prompt tends to backfire. Shorter, better-chosen context usually gives more reliable answers.
Is Context Engineering Only for Large Enterprises?
No. A 60-person company with a support bot needs it as much as a bank does. The scale is smaller, with fewer data sources and simpler access rules. Mid-sized firms can often move faster, because most of their know-how sits in a handful of systems and a few senior people’s heads.
Does Better Context Lower Running Costs?
It can. Model providers charge by the token, so trimming irrelevant text from every request shrinks the bill. Shorter inputs also tend to come back faster. Anthropic’s guidance favors keeping only high-value information in view, which helps accuracy and cost together. Your actual savings will depend on traffic volume and how the system is built.
Who Should Own Context Engineering Inside a Company?
Engineers build the pipeline, but they can’t own the facts alone. The people who know the business rules, such as operations or support leads, should own those. Gartner advises leaders to appoint a context engineering lead or team and connect that function with their AI engineering and governance teams.
How Long Does It Take to Fix Context in an Existing AI Pilot?
For a focused pilot with a few data sources, a context review and fixes often take four to eight weeks. Pilots that touch many systems or strict access rules take longer. The first step is an audit of what the model sees on real requests, which shows where the biggest gaps are.