Here's the thing.
We spent weeks perfecting a prompt for AI-assisted treatment notes in our dental SaaS. Tweaked the instructions. Tested formats. Adjusted tone. Tried different few-shot examples. The prompt was genuinely solid.
The output was still useless.
The model knew nothing about the patient. No history. No prior diagnoses. No visit patterns. We were asking it to write a meaningful clinical note while giving it zero clinical context. Like handing someone a blank form and asking them to fill it out from memory.
That moment reframed everything for me.
Prompt engineering is about how you talk to the model. Context engineering is about what the model knows before it even starts. And that distinction changes who owns the problem.
Gartner called 2026 "The Year of Context." Slightly dramatic. But accurate.
82% of IT and data leaders now say prompt engineering alone isn't enough to power AI at scale. My honest read: it was never enough. We just finally have vocabulary for the failure mode.
Context engineering asks a different set of questions:
- What data should the model have access to for this task?
- What tools can it use?
- Does it remember the previous conversation?
- Does it know who the user is?
- How long does memory persist?
These are PM questions. Not engineering questions.
Concrete example. You're building an AI feature that helps a doctor summarize a patient's situation at the start of a visit.
You can tell the model "summarize this patient's current status."
But the real question is: what does the model need to do that job well?
- Patient age, chronic conditions, active medications
- Summary of the last 3 visits
- Outstanding test results
- The doctor's prior notes
- The doctor's formatting preference — brief bullets or detailed narrative?
Who decides what goes on that list?
At most companies: the backend engineer who built the API endpoint makes a best guess, ships it, and moves on.
A product decision, made by an engineer on a Tuesday afternoon. Because nobody else claimed it.
Context engineering is a PM job. Four reasons.
Cost. Every token costs money. More context means higher API bills. That's a business decision — someone needs to own the tradeoff between context richness and margin.
Quality. Insufficient context produces generic output. Worse: wrong context produces confident, wrong output. A model that fabricates clinical details because it was given incomplete data isn't a technical failure. It's a product design failure.
Security. Context that crosses permission boundaries is a data breach waiting to happen. Deciding what user data gets surfaced to the model — at the product design level, not just the code level — is a compliance decision.
User experience. If the model says "I don't have information about this patient" on the first query, you've lost the user's trust. And that trust is very hard to rebuild.
All four dimensions — cost, quality, security, UX — land squarely in product territory.
Context engineering is technically complex. RAG architectures, memory management, tool orchestration, token budget allocation, context compression. Real depth under the hood.
But the decisions — what data to include, what to exclude, when to reset memory, what user context to surface, how long to retain session state — those aren't engineering decisions.
They're product decisions wrapped in a technical container.
The teams I've seen move fastest are the ones where PM owns the context strategy and hands implementation to engineering. Not the other way around.
This reminds me of the UX/UI split.
What started as "design" became two distinct disciplines. Different tools, different skills, different owners. The split happened gradually, then all at once.
Prompt engineering → context engineering is that same split, happening right now.
The question is: who in your product organization is doing context design?
If you don't have a clear answer, the answer is probably "nobody." The engineers are making reasonable guesses. But guesses aren't strategy.
After I started asking "what should the model know for this task?" instead of "is this prompt good?" — the conversation in our team changed. We started treating context as a product artifact. Something to be designed, reviewed, and iterated.
It sounds like a subtle shift. In practice it changes everything.
Who owns context design on your team?