
Elastic
View Brand PublisherFrom tokenmaxxing to context engineering: Why enterprise AI needs better context, not bigger prompts
Drawing on Elastic's experience helping enterprises build AI for production, Head of Field Engineering Ravindra Ramnani explains why context engineering is emerging as the next critical discipline for enterprise AI.
For a while, enterprise AI seemed to have a simple rule: if a model could process more information, it would produce better answers. As context windows expanded from thousands of tokens to millions, bigger numbers became synonymous with progress, and in response, organisations fed AI assistants entire document repositories and conversation histories.
At Elastic, this shift was evident as customers moved from pilot programs into production. The challenge was never whether AI could handle more data, but whether it was reasoning over the right data.
Tokenmaxxing began as a Silicon Valley workplace trend in early 2026: maximising AI token consumption as a signal of productivity. Some companies built internal leaderboards ranking employees by tokens burned, and high usage became a status symbol regardless of output quality. The trend drew sharp criticism because it measures inputs, not outcomes. “It is the AI-era equivalent of judging developers by lines of code," as Ravindra Ramnani, Head of Field Engineering, India, Elastic puts it.
The same fallacy shows up at the architecture level, where teams include irrelevant documents and conversation histories in prompts, assuming more information improves output. Models don’t filter unnecessary material like skilled analysts, resulting in more noise, slower responses, and outputs needing significant human review.
The gap became clear once organisations moved into production, where an agent acting on incomplete context doesn't just cost more; it produces consequential errors. "The conversation therefore shifted from 'how much can we give the model' to 'what does the model actually need to know.' That question lies at the heart of context engineering," says Ramnani.
What context engineering actually means
Context engineering is the discipline of deciding what a model sees at each step of its reasoning: which instructions frame the task, which tools are available, what is retrieved from enterprise systems, what is carried forward from earlier turns, and what is deliberately left out. In enterprise settings, the hardest part is retrieval, because the model has to be grounded in trusted internal knowledge without getting buried in it.
A simple analogy helps. Tokenmaxxing is handing someone an entire filing cabinet and asking them to find the relevant page. Context engineering is handing them the three pages they actually need, already tabbed. Both offer the same information. Only one enables better decisions.
Relevance isn't simply a search feature, either. It's the mechanism that makes autonomous AI safe to act on. When an agent reasons from incomplete data, the risk isn't just wasted compute. In a banking compliance workflow or a security operations centre, a wrong autonomous action can propagate before a human has a chance to intervene. The right information needs to be smaller in volume, higher in signal, and permission-controlled, so an agent only accesses what it's authorised to use. That combination of relevance and governance separates a reliable production agent from an expensive pilot.
How Elastic approaches it
Effective context engineering rests on three layers: data proximity, keeping the reasoning layer close to the source of truth rather than routing sensitive data through external pipelines; retrieval precision, surfacing only what is genuinely signal for a given decision, where Elastic's hybrid search, combining vector, keyword, and structured retrieval with semantic reranking, ensures what reaches the model is relevant rather than merely related; and execution grounding, loading agent capabilities on demand rather than arming every agent with a full toolkit on every turn, which reduces both token overhead and the risk of unintended autonomous action.
Elastic brings retrieval, tool creation, conversational grounding, and agent observability into a single platform, with the ability to deploy entirely on-premises or in air-gapped environments, and techniques like Better Binary Quantisation that reduce the vector memory footprint of retrieval data by up to 32 times while preserving accuracy.
This is also a business question before it's an engineering one: business teams need to define what good looks like before technical teams build for it, or organisations end up with elegant pipelines feeding agents the wrong data.
The impact is clearest in high-stakes decisions: security analysts getting only signals relevant to a specific threat rather than a generic feed, Financial Services and Insurance (FSI) teams grounding agents in the regulatory context of a transaction where CERT-In's 12-hour window and RBI frameworks create real pressure, and Global Capability Centres (GCC) developers getting answers grounded in their organisation's own systems. These use cases are particularly relevant in India, where enterprises operate across diverse data environments spanning legacy core banking systems and modern cloud-native applications, often with Hindi and regional-language records. With DPDP Act obligations and data localisation expectations, running the full AI stack on-premises or in air-gapped environments isn't a preference for many organisations, but a procurement requirement.
The most common mistake is assuming that connecting a model to enterprise data is the same as grounding it in enterprise context, since access doesn't guarantee relevant retrieval; a close second is treating agent observability as optional, leaving organisations unable to explain agent decisions to regulators.
Model selection will matter far less than the quality of context a model reasons over. A well-grounded smaller model consistently outperforms a larger model working from fragmented context, and competitive advantage is shifting away from model procurement, accessible to everyone at broadly comparable cost, toward the intelligence layer that determines what any model can actually know and do.
Enterprises also need to rethink how they measure AI success. Token usage and model size reveal little about business value. More meaningful measures are outcome-oriented: task completion rate against how often a human has to override it, decision accuracy in production versus testing, time-to-answer in high-stakes workflows, and regulatory auditability, an explainable record of what data an agent consulted and why.
Gartner projects that by the end of 2026, 40% of enterprise applications will incorporate task-specific agents, and systems without a unified, trusted data foundation don't just inherit the risks of individual agents; they compound them.
The organisations that extract the most durable value from AI won't be those that deployed earliest or chose the most sophisticated model. They will be those that invested in making their enterprise knowledge accessible, accurate, and trustworthy so that any reasoning system can act on it with confidence.
The model is not the moat. The data foundation is.

