The Data Stack and Why We’ve Had it Wrong for Decades

A colleague recently asked me an innocent question that stopped me in my tracks: “How is your data discovery different from ours?”

It was a fair question, but it exposed a structural flaw in how the industry thinks. We were using the exact same term to describe two fundamentally different universes. Their tool was focused on locating and cataloging text fields. Ours was focused on understanding heavily fragmented data in context, determining how it should be handled, and controlling what happens next.

That confusion has shaped enterprise technology for decades. We have treated data as though it were a single, uniform substance that can be stored, indexed, and protected using the same basic methods. The industry default has always been that data is data is data.

It simply isn’t true.

Anyone who has run complex enterprise architectures knows the reality. A clean customer record inside a transactional database is not the same as a broken string of numbers buried in a ten-year-old PDF archive. The risk isn’t just what you have stored; it’s what that information reveals when it is combined and used.

AI didn’t create this data crisis. It is just exacerbating the problem and making it impossible to ignore.

The Evolution of the Swamp

For thirty years, every generation of data architecture has promised to cure this headache. We moved data into warehouses to structure it. When the volume exploded, we built data lakes. Then came lakehouses, cloud platforms, and vector databases.

The underlying technology improved enormously. Storage got cheaper, compute got faster, tooling got better. But the central enterprise problem never disappeared.

Warehouses organized part of the data. Lakes accumulated the rest. Cloud platforms made it easier to move it around. But none of them answered the most critical questions: What is this information actually telling us? What can be inferred from it when combined?

Beneath the modern buzzwords, most large organizations are sitting on a fragmented information estate assembled across decades of acquisitions, legacy application shifts, and abandoned transformation programs. They don’t have one clean data environment. They have thousands of disconnected systems, overlapping copies, and vast multi-petabyte archives containing structured, semi-structured, and unstructured information.

The standard consulting advice is to spend millions on a massive “data hygiene” initiative to clean the swamp before deploying AI. It sounds responsible. It’s also completely unrealistic.

There is no magical point at which decades of enterprise history are fully cleansed. The objective cannot be universal cleanliness. The objective has to be fit-for-purpose at the moment of use.

Data States: Meaning Changes as It Moves

To understand why traditional tools fail, you have to stop viewing data as a static block. Data exists in distinct technical states as it moves through an architecture, and its risk profile shifts completely at every step:

• Stored Data: Raw, resting material. Easily boxed and contained. Manageable immediate risk, limited isolated utility.

• Indexed Data: Mapped just enough to make it locatable by a basic query.

• Searched Data: Selected because a user or system expressed a specific intent to find it.

• Graphed Data: Connected to other entities, exposing relationships that were invisible in the original records.

• Processed Data: Transformed into an active output, recommendation, or autonomous action.

A field containing a person’s name might be entirely low-risk while sitting as Stored Data. But the moment that name is pulled into a workflow, Graphed alongside a transaction history, and Processed by an AI model, the sensitivity skyrockets.

With AI, you are naturally combining data states, and by that very definition, creating an accidental liability exposure. Legacy security controls focus heavily on locking down files and databases. But the true risk of information only emerges after discovery has begun.

Discovery Is an Investigative Process

This brings us back to the core flaw of legacy tooling. Traditional platforms treat data discovery as a deterministic, single-pass event: crawl everything, match a regex pattern for a social insurance number, mask it, and output a report.

That works when data is perfectly cooperative. Enterprise data at scale is never cooperative.

Identifiers are split across disparate documents. Relationships are implied rather than stated. Scanned records contain broken layouts, and legacy systems use obsolete schemas. A pattern-matching tool might spot a string of digits without understanding that it represents an account number. A semantic search might find a relevant document but completely miss a crucial identifier tucked into a footnote.

True discovery isn’t an inventory check; it is an investigative process.

Think about how a human investigator works. They don’t type a single query and get the perfect answer. They enter a term, inspect the results, refine the criteria, follow a contextual clue, open a secondary source, and pivot. They begin with a name, discover an account, trace a transaction, and eventually expose a relationship that was invisible at the outset.

Legacy tools are expected to accomplish in one static pass what an experienced investigator does through a sequence of informed steps. It’s why multi-petabyte fragmentation leaves companies entirely blind.

The Sanitize-or-Destroy Trap

This investigative failure has created a ticking clock for highly regulated enterprises. Compliance frameworks are drawing a hard line: if you cannot confidently discover, contextualize, and flawlessly anonymize your historical, multi-petabyte data sets, you have a very short window before you legally must destroy it.

In the world of enterprise AI strategy where data is such a valuable commodity, this has become an existential crisis: act now or lose valuable insight. Decades of transactional history and behavioral insights are the exact high-value fuel required to train tomorrow’s custom models. Burning your own data satisfies the auditors today, but it bankrupts your competitive advantage for the next decade.

Regulated enterprises shouldn’t have to destroy their history simply because legacy tools were never designed to govern data at this level of scale, fragmentation and context.

Agentic AI Under Forensic Control

This is where agentic AI can materially change the data stack. Its real value is not simply giving agents the ability to write code or send emails autonomously. It is the ability to automate the iterative, investigative process that a skilled human would otherwise perform, while operating within a controlled and scalable workflow.

An agentic discovery system does not depend on a single static sweep. It decomposes a complex objective into a sequence of tasks, routes each task to the method best suited to the data and the question, whether that means a precise database lookup, semantic search, document analysis or graph traversal, and then evaluates the results before determining what should happen next.

That creates a fundamentally different form of discovery. The system can navigate fragmented data sources dynamically, follow relationships across different data states, isolate the information that matters and protect what is sensitive without treating the entire estate as one uniform problem.

The critical distinction, however, is control. Agentic AI operating under forensic control ensures that the appropriate tool is used for each task, that policy is enforced as data is discovered and processed, and that sensitive information remains protected across fragmented sources. It also preserves a defensible record of what was accessed, why it was used, which policy applied and what action followed.

That is what transforms agentic discovery from faster search into a governable enterprise capability.