Enterprise teams have been quick to embrace text-to-SQL as the go-to shortcut for building data-driven AI agents, but according to Simba Khadder, AI product lead at Redis, that shortcut comes with a hidden cost. In this exclusive VMblog Q&A, Khadder breaks down exactly where text-to-SQL breaks — not just syntactically, but semantically — and why letting agents write raw queries against production databases is a reliability and security risk most organizations are not prepared for.
The conversation goes deeper than just the failure modes. Khadder makes the case for a new discipline he calls context engineering: the practice of making the right data available to an agent at the right time, in the right form, with the right semantics. From curated semantic layers to unified context engines built on fast retrieval infrastructure, Khadder lays out a practical, incremental path forward — one that enterprise teams can start walking without waiting for a perfect data architecture that may never arrive.
++
VMblog: Text-to-SQL has been widely adopted as a quick shortcut to data-driven agents. Where specifically does it break down in enterprise environments, and what are the ideal alternatives to text-to-SQL?
Simba Khadder: Text-to-SQL usually breaks in the gap between syntactic correctness and semantic correctness. An agent may produce valid SQL, but that does not mean it understands which tables actually matter, which columns are authoritative, what the hidden quirks are, or how your business really defines things like a customer, an order, or fraud. In enterprise environments, that is the normal state of the world: overlapping schemas, years of historical baggage, partial documentation, and internal conventions that live mostly in people’s heads rather than in the database itself.
The other failure modes are security and performance. Once you let an agent generate raw queries against production systems, you are exposing yourself to over-broad access, accidental data leakage, and expensive queries that can hurt live systems. That is why I do not think direct SQL generation should be the default abstraction for enterprise agents. The better pattern is to give the agent a curated, schema-first context surface: business entities, attributes, and relationships exposed through a semantic layer the agent can navigate safely, rather than a blank check to write ad hoc SQL.
VMblog: You’ve argued that direct SQL execution by agents is risky. How do those risks show up in practice, and why do you prefer a curated context surface over direct database access?
Khadder: The practical risks show up very quickly. The SQL can simply be wrong, but more often the deeper issue is that the query is logically wrong while still looking plausible. The agent may join the wrong entities, use the wrong timestamp, read the wrong status field, or pull a result that is technically valid but operationally meaningless. In production, that is worse than an obvious error because it creates false confidence.
Then there is the operational side: access control, privacy, and database load. If an agent can execute raw SQL, it only takes one bad prompt, one bad tool call, or one injection path for that to become a security or reliability incident. Text-to-SQL systems also don’t issue a single query. Agents iterate, retry, and explore, which can turn one request into many queries and create sustained load on production databases.
In practice, teams already solve this by creating materialized views or projections into systems like Redis. They take data from systems of record, shape it for a specific access pattern, and serve it from a layer that is fast and controlled. A curated context surface follows that same pattern. Instead of exposing the full database, you expose a pre-defined, business-level view of the data. That preserves the agent’s flexibility while making the system far more controllable.
VMblog: A lot of enterprise databases are messy by nature, built without intention over the years, and inconsistently documented. How realistic is a “curated, schema-driven semantic layer” for organizations that are starting from that kind of foundation?
Khadder: It is realistic precisely because the underlying systems are messy. The point is not to pretend the systems of record are clean; the point is to stop exposing that mess directly to the agent. Most organizations are not going to fully clean up years of accumulated data architecture before they deploy agents. What they can do is build a context view on top of those systems: a controlled projection that joins the right sources, captures the entities that matter, and exposes only the context an agent should be allowed to use.
That is a much more practical path than asking for a perfect semantic layer everywhere on day one. You start with a narrow slice of the business and define the highest-value entities well enough for the agent to navigate them. In other words, this is less about boiling the ocean and more about building a reliable surface over the parts of the business where agent decisions actually matter. The discipline is real, but it is incremental and grounded in the same kinds of materialized views and data modeling patterns teams already understand.
VMblog: You mentioned this new era of context engineering. How would you define this for someone coming from a traditional data infrastructure background, and how does it differ from what teams are doing today?
Khadder: I would define context engineering as the discipline of making the right data available to an agent at the right time, in the right form, with the right semantics. For someone from a traditional data background, the closest analogy is a data pipeline or serving layer, but the consumer is no longer a dashboard, a human analyst, or a fixed ML model. The consumer is an agent that has to discover, retrieve, and reason over context dynamically while solving a task.
What is different from what most teams do today is that context is still treated as fragmented. There is one stack for RAG, another for memory, another for structured data access, and they often do not meaningfully connect. Context engineering moves toward a unified context engine: one semantic and access layer across unstructured data, structured data, and memory, so the agent is not bouncing between disconnected systems and abstractions. The shift is from retrieving a few chunks and hoping for the best to building a navigable context surface the agent can traverse.
This shift matters more as agents get better at reasoning. The amount of time an agent can run autonomously is doubling on the order of months which changes the problem entirely. As that happens, the bottleneck stops being intelligence and becomes access to the right context. Instead of trying to guess and pre-load everything the agent might need, you get more value by giving it a well-structured surface to explore and letting it find what it needs as it works.
VMblog: Redis is historically known as an in-memory data store and cache. What parts of that heritage make it well suited for the context engineering problem?
Khadder: What makes Redis relevant here is a pattern teams already understand well. For many production systems, they do not query systems of record directly for every request. They create materialized views or projections of their data, shape it for specific access patterns, and serve it from Redis as a fast, controlled layer. Context engineering follows that same idea, except the consumer is now an agent that needs to retrieve and update context continuously while reasoning.
That foundation maps directly onto agent systems. Short-term memory, long-term memory, semantic caching, vector retrieval, and structured lookups all need to happen quickly and often in the same loop. Redis has spent years solving exactly that problem for web applications, and the same primitives extend naturally to agents.
The other reason is versatility. Context engineering is not one retrieval pattern. Sometimes you need vector search, sometimes text search, sometimes a key-value lookup, sometimes a time-oriented or relationship-oriented lookup, and sometimes memory needs to be updated as the agent works. Redis’s history as a general-purpose, real-time data layer turns out to be a strong foundation for serving context in all of these forms.
VMblog: For an engineering team that has already shipped a text-to-SQL agent into production, what does the path toward this more disciplined approach look like?
Khadder: The first step is not to rip it out immediately. The better move is to study where it actually works, where it produces plausible-but-wrong answers, and where it creates operational risk. Those failure cases usually tell you which parts of the domain need to be pulled up into a higher-level abstraction first. In practice, that means identifying the core business entities behind the most important workflows and defining a constrained semantic layer around them.
From there, the migration path is to replace raw query generation with curated retrieval surfaces one domain at a time. Start with the high-value use cases, define the schema first, expose the relevant relationships, and let the agent navigate that surface instead of the raw database. Over time, you can unify that structured context with memory and unstructured retrieval so the agent stops being a text-to-SQL wrapper and starts acting like a system that can discover and assemble context safely. The point is not less agent autonomy. It is giving that autonomy a better environment to operate in.
##
