March 2026 · 5 min read · Part 1 · The Agentic Enterprise
What an Agent Is (and Isn't)
A chatbot gives you a bad answer and you shrug. An agent gives you a bad answer and someone acts on it. The industry is calling everything an agent, and the gap between the demo and reality is where executive decisions go wrong.
Last month, I watched a team demo an AI agent they had built on their data warehouse. It could answer natural language questions about pipeline, pull customer records, and generate summaries of account health. The demo was flawless. The VP of Sales asked it to identify which enterprise accounts needed intervention before quarter-end.
The agent returned a prioritized list. Three of the accounts on it had already renewed. Two were test accounts the sales engineering team used for demos. One was a subsidiary that had been merged into its parent entity eight months ago and no longer existed as a distinct customer.
The agent was not hallucinating. It was reasoning correctly over data that did not represent reality. The entity model underneath it had no concept of account lifecycle, no resolution between parent and child entities, no flag distinguishing test data from production data. The agent found patterns in what was there. What was there was wrong.
This is what separates agents from chatbots. A chatbot gives you a bad answer and you shrug. An agent gives you a bad answer and someone acts on it.
The spectrum nobody admits they’re on
The industry right now is calling everything an agent. A chatbot with a system prompt is an agent. A retrieval pipeline with a summarizer on top is an agent. A scheduled query that sends a Slack notification is an agent. None of these are agents.
An agent operates autonomously within boundaries. It perceives a situation, decides what to do, and takes action without a human in the loop for every step. The boundaries are the hard part. Not the model, not the reasoning capability, not the integration. The boundaries.
Most companies claiming to have agents are at step two on a five-step spectrum, calling themselves step five. A chatbot that queries structured data. Maybe a workflow that fires when a threshold is crossed. That is fine. A well-built tool is more valuable than a broken agent. The problem is not where you are on the spectrum. The problem is pretending you are somewhere you are not, because that is how the VP of Sales ends up acting on a list of dead accounts.
The “just connect it” catastrophe
I need to be direct about this because I am watching it happen in real time: connecting an LLM directly to your data warehouse is one of the most dangerous things you can do right now. Not dangerous like “the output might be slightly off.” Dangerous like “your executive team will make decisions based on confidently wrong information and not know it until the damage is done.”
Here is what happens when you give Claude or ChatGPT a database connection and tell it to answer business questions:
It invents joins. The model sees tables with similar column names and connects them. Sometimes it joins your production customer table to an archived staging table from a migration two years ago and doubles your customer count. The answer comes back clean and formatted. Nothing in the output signals that the join was wrong.
It guesses at definitions. A column called status could mean account status, order status, subscription status, or approval status. The model picks one interpretation and commits to it. It will never tell you it guessed, because guessing is what language models do. They do it fluently.
It ignores access controls. Your warehouse has role-based access for a reason. Certain tables contain compensation data, customer PII, financial projections not yet shared with the board. An LLM with a database connection does not understand organizational boundaries. It will happily surface data that the person asking was never supposed to see.
It hallucinates aggregations. Ask it for “average deal size by segment” and it will produce a number. Whether that number accounts for currency conversion, excludes internal deals, or matches the number in the board deck is entirely a matter of luck. There is no mechanism for the model to know it got the aggregation wrong.
It cannot distinguish current from historical. Your warehouse contains years of data. Some records reflect current state. Some reflect states that no longer exist: discontinued products, restructured territories, definitions changed mid-quarter. The model treats all of it as equally valid.
I have seen all five of these failure modes in production. In one case, a sales leader reallocated territory coverage based on a segmentation analysis the LLM had constructed from a deprecated classification schema. The correct schema was in a different table with an almost identical name. Nobody caught it for six weeks.
The appeal of “just connect it” is obvious. It is fast. It demos well. It feels like you shipped an AI capability in a week. But what you shipped is an unvalidated oracle with access to everything in your warehouse and no understanding of what any of it means. The first time it contradicts the trusted report, and it will, the trust damage sets back your entire AI program by months.
This is not a problem you solve with better prompts or more documentation in the context window. It is a structural problem: the model has no business context, no semantic model, no entity definitions, and no guardrails. It is reasoning from syntax, not from meaning.
The next post is about what works instead.