VeloDB’s Nitin Waghulde on why AI agents break down after the demo

An AI agent is a software system that uses data, reasoning, and repeated searches to complete a task. It differs from a traditional report, which follows a fixed path and usually returns a known metric in one lookup. It also differs from a basic chatbot because the article describes agents as actively gathering and combining information rather than only responding from a narrow conversation flow.

For example, a manager can run a report for last year’s sales figure. An agent asked why sales dropped over three quarters may search ERP and CRM records, support tickets, chats, and sales reports. If its reasoning is incomplete, it searches again. Its loop is: ask, think, search, and retry.

This makes agents more capable but harder to operate. They create unpredictable demand on data systems and need broad access, scale, freshness, and complete interaction records. A pilot may hide those requirements because its questions and data are controlled.

An agent can look successful in a pilot because the scope is narrow, the data is controlled, and questions are predictable. Those conditions reduce the number of searches and make failures easier to manage. Production removes those guardrails. Agents face live business questions, more users, more data sources, and decisions that depend on current information.

The article gives a sales example. A pilot might answer a prepared question, but a production agent investigating falling sales may search ERP and CRM records, support tickets, chats, and territory reports. It may repeat the process when its reasoning is incomplete. Agents also run around the clock and ask many questions at once, creating an unpredictable load.

The data layer becomes the limiting factor. Production systems need every data type, large-scale concurrency, immediate updates, and complete interaction records. Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027 because of cost, unclear value, or weak risk controls.

The article’s clearest comparison is between one traditional lookup and hundreds of agent lookups. A business manager asking for last year’s sales figure can use a ready-made report. An agent explaining why sales declined over three quarters must gather evidence, compare sources, and revisit its searches when its reasoning is incomplete.

It may pull order records from ERP and CRM systems, inspect support tickets and chats, and read sales reports about territory dynamics. Nitin Waghulde said that work which once took “one simple lookup or one simple query” can now involve hundreds of lookups for the same answer. The agent’s iterative loop creates the extra work.

The exact increase depends on the task, so the article does not provide a universal multiplier. It does show why systems designed for ordinary reporting can struggle. Agents also search concurrently and may scan petabytes of data, increasing both cost and pressure on the platform.

Agents depend on data to reason and act, so stale, incomplete, or conflicting information directly weakens their decisions. The article compares stale data to driving with an inaccurate traffic map: the system may still move forward, but its direction cannot be trusted. When sources disagree or omit important context, users also struggle to understand where the answer came from.

The refund example makes the risk concrete. If an agent processing a refund cannot see the latest transaction record, it has to wait. More broadly, an agent investigating sales may miss an escalation in support chats or rely on an outdated business record. Its conclusion can then be incomplete, delayed, or wrong.

Production agents therefore need freshness, not just stored data. Updates and deletions should become visible immediately instead of waiting for a nightly batch. They also need a record of every interaction, helping organizations trace how an answer or decision was produced.

Business answers rarely live in one format. Structured records hold transactions and other precise numbers. Documents, chats, and reports contain explanations, exceptions, and human context. Vector stores support meaning-based search across unstructured material. A production agent needs to combine these forms because a useful answer often depends on evidence spread across the business.

For example, explaining falling sales may require order data from an ERP or CRM, customer escalations in support tickets and chats, and sales reports about territory dynamics. Looking only at transactions could show what changed but not the reasons behind it. The agent searches each source and combines the results before answering.

This breadth creates a data-infrastructure challenge. Each extra trip adds cost and delay, while scattered sources make answers harder to trace. The article says production agents need access to every data type. Bringing those searches together can provide a more unified source of truth, with fresher and more explainable results.

Hybrid querying addresses the repeated-search problem by combining different search methods in one query. SQL handles structured business data. Text search finds words and phrases in documents or conversations. Vector search finds material by meaning. Running these deterministic and probabilistic searches together can reduce the separate trips an agent would otherwise make.

The article describes VeloDB’s approach as a single query that combines SQL, vector search, and text search in parallel. An agent investigating sales could therefore bring together order records, support conversations, and relevant reports without separately visiting each system and waiting between requests. The result is intended to be one unified source of truth.

This matters because every additional trip adds cost, and agents may repeat searches when their reasoning is incomplete. Hybrid queries do not remove the need for fresh, complete data or adequate scale. They provide an infrastructure mechanism for reducing back-and-forth as agents handle larger workloads and concurrent conversations.

A database is a system for storing and retrieving data, while also managing changes and serving information to applications. For AI agents, it is more than a passive warehouse. It becomes the foundation that supplies records, documents, search results, and interaction history as the agent asks questions and retries. If that foundation is slow, incomplete, or outdated, the agent cannot reliably reason or act.

The article describes production requirements that expose the database’s role. Agents may need to search structured records, documents, chats, and vector stores. A single query may scan petabytes, and the platform must support many concurrent, iterative queries. Every update and deletion should be visible immediately, including the latest transaction during refund processing.

A strong data layer can reduce repeated trips through hybrid queries that combine SQL, text, and vector search. It must also record every interaction. As agent workloads expand, database design becomes central to cost, trust, freshness, and dependable production operation.