The manager in charge of the customer support system saw the escalation email ten minutes before he was supposed to leave for the day.
A customer had asked, in a chat window, whether they could also check on "my friend's order." The company's newly launched AI support agent responded by handing over another customer's complete order history and contact information. Security shut the feature down within two hours. Legal wanted an incident report: who approved this agent going live, and why could it "see" data it was never supposed to touch in the first place?
(The scenario above is illustrative, describing a pattern that has already become common across the industry โ it does not refer to a specific, identifiable customer incident.)
This isn't a dramatized hypothetical. Business strategist Bernard Marr, on his own business and technology podcast, points directly at incidents like this already happening in the real world: "We've seen this in practice, where AI agents have deleted mission-critical data, leaked sensitive business information they shouldn't have shared, simply because certain safeguards weren't in place." On that episode, he brought on Masimo Merlo of Elastic to dig into what's actually behind this string of failures โ and the answer isn't that the models aren't smart enough. It's that most enterprises are missing a piece called "context engineering."
You Think the Problem Is the Model. It's Actually the Foundation.
Masimo opens with a blunt observation: the experimentation phase of enterprise AI is over. Most organizations have already run their pilots, and now they're staring at the uncomfortable gap between what AI promised and what it's actually delivering.
He traces the root cause back further than most people expect. Enterprise software has been built up in layers over the past four or five decades โ a data layer, a context layer, an application logic layer, a user experience layer. AI is now scrambling and reassembling all of those layers at once. Any organization that assumes it can just "plug a model into the existing system" and wait for a miracle quickly discovers that its data flows were never designed for AI, and its governance hasn't kept pace with the speed of the change. Bolting a powerful model onto a foundation that was never cleaned up doesn't produce transformation โ in Masimo's words, it produces "a more confident version of the same old problem." What AI is genuinely good at is generating wrong answers, very efficiently, when it's fed the wrong information.
If AI Is the Brain, Context Is the Memory
So what is context engineering actually solving for? Masimo offers a metaphor he'd heard and found fitting: if AI is the brain, context is the memory. No matter how fast a brain can process information, without memory โ without experience, without a record of what's already happened โ it can't judge what the right decision is right now.
The same logic applies to enterprises. A model trained on the public data of the entire internet doesn't automatically understand "you" โ it doesn't know your customers, your policies, what's happened in your organization's history, your risk tolerance, or what you're actually trying to achieve. It processes data and produces an answer that sounds reasonable but is fundamentally generic. What context engineering does is turn "connecting the right data, to the right model, at the right moment" into an actual discipline: defining what the model is allowed to see, and building guardrails so its output is something you can trust and safely act on.
From Annoying to Dangerous: Once AI Starts Making Its Own Decisions
Masimo draws out a specific turning point: when AI is only answering questions, a wrong answer is at worst an inconvenience โ you catch it and correct it on the spot. But once AI becomes an agent that recommends, decides, and acts on its own, the exact same kind of wrong answer becomes something entirely different โ a business risk, a regulatory exposure, or a security incident.
He gives two concrete examples. One is an agent operating inside a security operations center (SOC): it needs real-time threat intelligence, historical incident records, and a clearly defined escalation process โ miss any one of those, and its judgment goes off the rails. The other is a fraud detection agent: it can't evaluate a single transaction in isolation. It needs the customer's transaction history, the policies that apply, the organization's risk thresholds, who has authority to act, and what kind of audit trail needs to exist afterward. Strip all of that away but hand the agent full authority to act, and what you get isn't a "slightly weaker" agent โ it's a genuine liability. This is exactly the logic behind the support-agent incident at the top of this article.
Why "Just Move All the Data Next to the Model" Is a Trap
Following that thread, the conversation turns to the role of real-time data. Masimo's point is direct: an AI system is only as current as the data it can see. If its decisions are based on a snapshot of the world from two years ago โ or longer โ the result isn't just "less useful." It's simply wrong.
Many enterprises' first instinct is to centralize all their data next to the model. Masimo argues that's impractical in reality โ enterprise data is too large, too sensitive, and too distributed to keep moving around. The smarter approach is to let AI access data where it already lives, through governed, trustworthy, real-time access โ rather than relocating the data itself.
That's also why retrieval hasn't become obsolete with the rise of generative AI โ if anything, it's become more critical. Early on, the market wondered: if a model can generate answers directly, why do you still need retrieval? Masimo says the opposite is true โ retrieval and the context layer are the infrastructure that finds the right information, understands what it means, and delivers it to the AI exactly when it's needed. That infrastructure is what determines whether an AI's output is actually trustworthy, or just sounds convincing.
Good Context Engineering Doesn't Start With Picking a Model
So what does this look like in practice? Masimo offers a concrete test: the most common first mistake in an AI project is treating deployment as a "model problem," when it's almost always a "workflow and data problem." Organizations that get this right don't start by asking "which model should we use" โ they start by asking "what does this model need to see." That means starting from the workflow itself, understanding what data that workflow depends on, defining permissions clearly, and leaving a traceable record of the whole process so you can see exactly what the AI actually did in production. Without that foundation, Masimo is blunt: what you have is just "a chatbot that looks cool."
Bernard and Masimo agree on this point: the model itself isn't a competitive advantage, because everyone has access to roughly the same models. What actually creates the gap is the quality of the data an organization has accumulated internally, and its ability to redesign its own workflows. This echoes a comparison Masimo made earlier to the shift to cloud computing โ many enterprises simply "lifted and shifted" their existing systems into the cloud, expecting problems to resolve themselves, and ended up creating more problems instead. The same trap is playing out again with AI: bolting a powerful model onto a broken workflow and calling it a strategy tends to fail.
The Turn: You Solved "Will Something Go Wrong," But You Might Be Paying a Different Price
The word "token" never came up once in the interview, but the logic behind context engineering runs into a reality that no enterprise adopting generative AI can avoid โ this is an observation we've extended from a token governance angle, not something either speaker said directly.
The more completely you feed context โ historical records, policy documents, audit trails, real-time data โ the more content the model has to process on every single call, and that's exactly what drives token usage and cost. This is also why governance can't stop at just "safety" and "accuracy." Context that hasn't been curated often means dumping in everything you can think of, producing a bloated, messy input where every call is paying for information that's duplicated, outdated, or irrelevant. Context that's actually been governed โ keeping only what's genuinely needed for the task at hand โ tends to be leaner and more precise instead. In other words, doing context engineering properly often solves two problems at once: whether the answer can be trusted, and how much each call actually costs. The second one just gets overlooked more easily, because the bill usually doesn't land on finance's desk until the following month.
Before Your Next AI Project, Ask "What Does the Model Need to See?"
Masimo's outlook for the next three to five years is that enterprise AI will become more "agentic," embedding itself deeper into security operations, observability, customer service, and even frontline software development workflows. But the organizations that end up ahead won't be the ones that deployed fastest โ they'll be the ones disciplined enough to build the foundation first: the data foundation, the context layer, the governance architecture. He sees the market already splitting into two paths: one is "brute force" โ repeatedly throwing expensive, redundant model calls at problems that a better context infrastructure could solve more intelligently. The other puts its effort into extracting meaning from data and treating context engineering as the top priority, letting the system get more accurate and more valuable over time instead of starting from scratch on every task. It's the second group whose foundation keeps compounding over time, making it structurally harder and harder for anyone else to catch up.
Back to the scenario that opened this article: if the support manager had asked, before that feature went live, not "is this agent smart" but "what can it see, who approved it seeing that, and has this actually been tested" โ that escalation email might never have existed. That question matters more than which model you pick, and it has a more direct bearing than most people realize on what next month's bill actually looks like.
FAQ
Q1: What is context engineering? According to Elastic's Masimo Merlo, it's the discipline of connecting "the right data, to the right model, at the right moment": defining what enterprise data (customer records, policies, historical incidents, and so on) an AI model is allowed to see, and building guardrails so its output can be trusted and safely acted on.
Q2: Is context engineering the same thing as RAG (retrieval-augmented generation)? The two are closely related but not identical. The retrieval and context layer discussed in the interview is one key piece of infrastructure that lets AI access accurate data in real time. Context engineering is broader โ it also covers permission design, data governance, process monitoring, and guardrail construction. It's an organization-wide engineering discipline, not a single technical technique.
Q3: Why does context matter more for AI agents than for ordinary chatbots? Because when a chatbot gets something wrong, the user catches it and corrects it on the spot โ at worst, an inconvenience. But once AI can autonomously recommend, decide, and act, that same wrong answer can turn directly into a business risk, a regulatory exposure, or a security incident. The interview describes this as the shift from "annoying" to "dangerous."
Q4: What's the first step for an enterprise adopting context engineering? Based on the criteria Masimo lays out in the interview, the first step isn't picking a model โ it's starting from the workflow: figuring out what data that workflow depends on, defining clear access permissions, and making the whole process observable and traceable so you always know what the AI actually did in production.
Q5: Does context engineering increase or decrease AI token costs? The interview itself didn't discuss token costs, but extending the logic, both outcomes are possible: dumping every piece of data you can think of into context will bloat the size of every call and drive costs up. But following the interview's own logic โ keeping only the data the current task genuinely needs โ tends to make each call leaner and more precise, improving both the trustworthiness of the answer and cost efficiency at the same time.
Source disclosure: This article is adapted and reinterpreted from an episode of Bernard Marr's business and technology podcast, titled "Why Context Is The Missing Piece In Enterprise AI (https://www.youtube.com/watch?v=mNSJC7UEbxc)," featuring guest Masimo Merlo of Elastic, published on 2026-07-02 with 79,830 views (verified via Apify at the time this transcript was captured). All descriptions of context engineering, enterprise examples, and future trends in this article are adapted from the interview transcript. The section on "context engineering and token cost" reflects an extended viewpoint from the AI Token King editorial team based on the interview content, and is not something either speaker said directly โ noted here for clarity.
Further reading: We've also covered what OpenAI Codex actually is and how it differs from ChatGPT and Claude Code for non-technical users, why AI tokens are so expensive once you break down how autoregressive generation actually burns through them in coding agents, why more software is shifting to token-based pricing as AI agents change enterprise procurement and cost governance, and why a stronger model release can put an entire AI product's moat at risk.
Understanding "what the model needs to see" is only the first step. The next question people tend to overlook is what those calls actually add up to in dollars. Try AI Token King free (https://aitokenking.com.tw/home) and bring the usage and cost of every AI model you call through a single key into one dashboard โ so you're not seeing that number for the first time when next month's bill arrives.
