When the Three-Layer Analytics Stack Was Actually Correct
The enduring logic of collect, store, and act survives tool consolidation and AI.

The three-layer analytics stack was correct because it separated three enduring concerns, which are collect, store, and act. It did not need to predict the tools that would serve them. The growth of specialist layers, vendor consolidation, and AI agents has tested those boundaries, which have stayed in place. Their endurance offers a practical guide to building analytics infrastructure that can survive the next change in tooling.
What the three-layer model actually said, and what it didn't
The Three-Layer Data Stack Framework organized the architecture around ingestion and storage, processing, and analytics. These were sequentially dependent stages, each with a distinct job. In practical terms, the system had to collect data, store it in a form that could be reasoned over, and let a consumer act on what it revealed. The claim concerned the work an analytics architecture must do, independently of the number of products needed to do it.
That distinction matters because a logical concern is not the same thing as a deployment boundary. Ingestion and storage can sit together in a description of the architecture even though each has different needs. Processing can make stored data ready for use without being a separate top-level concern in every description of the stack. The useful reading of the framework is therefore not a rigid allocation of every operation to a box. It is a statement of dependencies between acquiring data, making it usable, and applying it.
The model did not name tools, commit to batch or stream, or predict how many specialist functions would emerge. Those choices belonged to implementation. Its stack metaphor borrowed from software engineering, where each layer depends on the one beneath it and components can change without forcing a complete rebuild. The test of the model is consequently whether those dependencies held as implementations changed. A longer list of tools would disprove a product inventory, but not necessarily an architecture.
How the layers multiplied without moving the boundaries
The proliferation of categories since 2021 made the stack look less like three layers and more like a collection of specialties. Yet each category made a job the stack already had to do clearer. Collection divided into batch and CDC ingestion, streaming, and event capture. Fivetran and Airbyte, Kafka and Confluent, and clickstream tools such as Segment and Snowplow serve different collection requirements.
Storage followed the same pattern. The warehouse, lake, and lakehouse answer different versions of the need to house data for downstream queries. Vector databases such as Pinecone and Weaviate extend that requirement to AI workloads. The forms differ because the queries differ. A new way to organize data does not eliminate the need to distinguish its arrival from its use.
The act concern also became more explicit about its consumers. Presentation tools such as Tableau and Looker deliver data to people, while Streamlit supports data apps. Reverse ETL through Hightouch or Fivetran Activations (formerly Census) makes data available for activation. Orchestration through Airflow, Prefect, and Dagster connects the work needed to make the system’s output reliable.
Observability and data quality provide the clearest demonstration that more categories do not necessarily mean more logical layers. DataHub, Monte Carlo, and Great Expectations make quality, lineage, and contracts explicit across the pipeline. Those responsibilities were already implicit in storing data in a form that could be trusted. In a mature stack, observability is therefore a horizontal fabric.
Why the logical boundaries held even as the tools kept changing
The boundaries held because the three concerns answer to different constraints. Collection is governed by source systems and latency. Storage is governed by cost, query shape, and governance. Activation is governed by the decision-making context of the consumer. No change in packaging makes a source system’s delivery constraints identical to a consumer’s requirements for action.
Those differences also produce distinct failure modes. Broken connectors and schema drift call for ingestion fixes, while ballooning costs and governance gaps call for storage fixes. Dashboard sprawl, low adoption, and stale metrics belong to presentation. A failure downstream does not, by itself, mean the upstream layer has failed. Treating every problem as a defect in the same undifferentiated system obscures the responsibility that needs attention.
The warehouse’s emergence as a gravity well made storage the dominant design constraint around which ingestion and presentation reorganized. That is a shift in the center of the architecture. The software stack analogy still fits because parts that depend on the same central component can each do a different job.
The move from ETL to ELT makes the distinction concrete. Transformation moved relative to loading, but collection, storage, transformation, and action remained necessary work. ELT put that work in the order collect, store, transform, and act. The implementation changed where processing happened without removing the need to acquire data, make it usable, or deliver it to a consumer.
The Fivetran–dbt merger as an industry verdict on the model's shape
The Fivetran and dbt Labs merger, completed June 1, 2026, packages the full ingestion-to-transformation stack within a single modern cloud-native ELT vendor. Fivetran brought ingestion connectors at the collect end of the architecture. dbt Labs brought transformation into governed analytical models at the upstream part of the store concern.
The portfolios were not pure diagrams of the layers. Fivetran also had reverse ETL via Census and SQLMesh via Tobiko Data. A vendor can serve more than one concern without making those concerns interchangeable.
As an industry verdict, the merger supports the view that ingestion and transformation form a useful unit of purchase. Their boundaries were distinct enough to support separate products for years and stable enough to combine without confusion about their roles. The market’s consolidation around that shape is consistent with the model’s account of upstream dependencies. It does not establish that those dependencies have become one indivisible task.
The counterargument is that a single vendor means the layers themselves are merging. But a shared supplier does not settle what gets ingested or what transformation logic should govern it. A team still has to make those decisions separately. Consolidation can change the commercial boundary while leaving the architectural boundary intact. That difference explains how fewer vendors and more specialist capabilities can coexist within the same logical model.
Where AI agents expose which architectural decisions were actually correct
AI agents apply a new load to the existing concerns. Their significance is that mistakes can now feed autonomous action instead of waiting for a person to interpret a dashboard. A choice that was acceptable for one consumer can become a liability for another. Agents therefore test whether the architecture split up the work for reasons that still hold or to fit the limits of its first interface.
Collection exposes this change through latency. Batch schedules can work for human analysts who check dashboards each day. Agents that make decisions affecting real money, inventory, or customer experience need data that is less than hours old. Freshness still matters, but how long the data can wait depends on who uses it.
Storage faces a related change in trust. Traditional access control is user-based, while AI systems need rules about what an agent may access, under what circumstances, and for what purposes. The stored data must therefore carry more than a usable schema. Alation describes context as a fourth requirement alongside the original three, giving agents the meaning and judgment they need to act on what they retrieve. Architecturally, that is an expanded responsibility inside the storage layer.
Activation must also serve a different consumer. The third layer now needs to be agent-queryable rather than only a presentation layer for human dashboards. Its job remains to deliver information in a form the consumer can act on. Letting agents query production databases directly bypasses that distinction by treating an operational system as the analytical storage layer. Because the systems have different optimization targets, collapsing them creates security and performance risk and leaves the serving requirement unresolved.
Why governance becomes more critical when agents are querying the data layer
The change in consumer makes ambiguity more immediately costly. A human analyst can use institutional knowledge to reconcile an inconsistently named column or recognize that a metric needs interpretation. An agent has none of that implicit knowledge. Ungoverned definitions, naming gaps, and permission gaps can thus feed into automated execution without a human there to correct them. What once depended on informal understanding must now be expressed in the governed data.
Alation distinguishes a traditional stack that makes data available from a modern data stack for AI that makes data understandable and actionable to machines. Availability alone does not establish meaning. A queryable value still needs a definition that fits the business decision, and access still needs to fit the agent’s purpose. These are not presentation details that can be deferred until after the data is served. The consumer can use the data correctly only when these requirements are met.
The revenue conflict between two dashboards shows why this matters. When both draw on the same underlying data but return different revenue figures, a human team argues about the numbers before making a decision. An agent querying that ungoverned layer can act on one figure without flagging the conflict. The underlying disagreement remains the same as its position in the decision process changes. Instead of interrupting action, it becomes an input to action.
Pre-modeled, pre-calculated datasets that encode business definitions as facts address the conflict. That gives human and agent consumers the same governed source rather than leaving each interface to reconstruct meaning. It also locates the definition where it can remain independent of the tool that presents or queries it. Governance becomes part of the serving contract.
What the original model's endurance tells builders about the next wave
New tools should be evaluated by the concern they address. Evaluating a tool requires establishing whether it changes a logical boundary or makes a sub-concern inside an existing one more explicit. This is a way to distinguish useful specialization in new categories or integrated products from a claim that a necessary responsibility has disappeared.
Claims that collapse collect and store into one system, or store and act into one interface, need a more specific test. They should be evaluated against the failure modes that motivated the separation. Evaluating those claims requires asking what breaks when one tool serves two different optimization targets. A single product may cover both responsibilities, but its packaging does not answer that question. The architecture still needs a clear account of the trade-off.
For startups, Supabase provides a concrete instance. Supabase Postgres is a strong operational system, but running analytics on the primary damages transactional performance. Separating transactional and analytical workloads is therefore not a bureaucratic preference. It follows from the different demands placed on the system. Taking a component out of a diagram leaves the competing work it was meant to keep apart.
For founders, getting those logical boundaries right early is more durable than optimizing the initial vendor selection. Tools will change, while the stack will still need collection, trustworthy storage, and action. A single governed data layer, rather than per-tool definitions, keeps the team and its agents aligned on one set of numbers through those transitions. The next wave can change how each concern is served.
Sources
- From ETL to Modern Data Stack: A Systematic Review and Strategic Implementation Framework
- Agentic AI and Data Access Control as the New Security Perimeter
- Agentic Data Environments
- Deontic Policies for Runtime Governance of Agentic AI Systems
- From AI-Generated Content to Agentic Action: Security and Safety Threats in Generative AI


