Blog

AI Agents

From Warehouses to Operations: Why Agent Architecture Differs

Learn why agent architecture differs from data warehouses and how operational agents require new design patterns for real-time action.

Michel Tricot

Jan 29, 2026

Updated Jun 29, 2026

•

3 min

Summarize with AI:

From Warehouses to Operations: Why Agent Architecture Differs

Some data and AI leaders assume their existing infrastructure will power agents. They've invested millions in data warehouses, transformation pipelines, and semantic layers. The underlying assumption is that clean data and APIs are already in place, and agents are simply the next consumer in line.

That assumption is where most projects fail.

The Triumph of the Warehouse Era

We built something remarkable. The modern data stack gave organizations a reliable way to make sense of complex systems at scale.

Pipelines moved data from operational systems into warehouses. Clean schemas and transformed models made that data usable. Analytical queries surfaced patterns across millions of rows, and dashboards brought it all together. Executives could see churn rates, revenue trends, and customer segments at a glance.

This infrastructure was built for aggregation, pattern discovery, and understanding the past. It aligned with how humans consume information: analysts ran queries, dashboards refreshed on schedules, and reports arrived in inboxes.

The data stack helped people understand the past, but it rarely carried that understanding into action.

The Question Warehouses Answer

Warehouses excel at answering one fundamental question: "What happened?"

They analyze things like what happened across customers, which segments are growing, and where revenue is being lost. They aggregate millions of rows to surface trends, identify patterns, and inform human decision-making.

The architecture reflects this purpose. Batch pipelines sync overnight. Columnar storage is optimized for large scans. Query engines are built for aggregation, and semantic layers define metrics consistently across the organization.

Every design choice assumes a human in the loop. Analysts interpret charts, product managers drill into cohorts, and finance teams reconcile numbers in spreadsheets. Insight flows to people, and people decide when and how to act.

The Question Agents Need to Answer

Agents don't ask what happened. They ask what to do right now about a specific entity.

When a support agent receives an incoming customer message, it doesn’t need to know churn rates across all customers. It needs context on this one person: what they’ve done recently, what they’ve bought, any open support tickets, and their past conversations with the company.

From there, it needs to act. It might update a record, escalate to a human, or trigger a refund. This requires live, entity-specific access to information across multiple systems, fetched at the moment it’s needed.

This difference shows up in how information is used.

Traditional data systems organize information so humans can study it through dashboards and reports. Agent systems need context that they can reason over and act on immediately. That context is situational, tied to a specific entity, and short-lived.

The Architectural Mismatch

You can't just point an agent at a warehouse. The mismatch is immediately apparent.

Timing and Information Flow

Warehouses sync on schedules. Nightly jobs, hourly updates, maybe incremental loads. That's fine when you're building a dashboard. It's disastrous when an agent is in a live conversation with a customer and needs to understand their current status. The agent needs to see the current state, not historical snapshots from the warehouse.

The issue is not just freshness. Warehouses assume data is pushed in ahead of time and queried later. Agents need on-demand access. When a customer message arrives, the agent must immediately pull that customer’s latest state across systems. Batch-driven information flow can’t support this.

Access Patterns and Interfaces

Warehouses optimize for throughput and historical analysis. They move entire datasets through compression and columnar storage to extract patterns. An agent needs the opposite: fresh, entity-specific data about one customer, one transaction, one ticket.

This mismatch extends to how data is exposed. Warehouses rely on SQL and BI interfaces built for human analysts. Agents need APIs, SDKs, and structured endpoints that let them fetch specific entities programmatically, without writing SQL.

Data Models

Warehouses use dimensional modeling. Fact tables, dimension tables, and slowly changing dimensions. This works for aggregate analysis. But agents reason about entities, not dimensions. The entity cache is the new way of organizing data, overtaking the star schema.

If you try to serve agents from your warehouse, you'll hit stale data, high latency, no write path, and no way to fetch entity-specific information in real time.

The Consumer Shift

One often overlooked point is that the people building agents aren’t data engineers.

Data engineers built the warehouse era.

These engineers understood batch processing, data modeling, transformation logic, and orchestration tools. They worked with tools like dbt and Airflow and optimized for data quality and pipeline reliability.

Software engineers and AI engineers are building agents.

These engineers have different mental models, different tools, and different expectations. They think in APIs, not pipelines, and expect real-time responses rather than scheduled syncs. They want to call a function and get data back, not write SQL against a data model they didn't design.

Concepts that are obvious in data land are unknown in AI land.

ETL, ELT, slowly changing dimensions, data lineage. These ideas don't translate. The AI engineer building a support agent might have never heard of a fact table. They just want to know if they can get this customer's ticket history in under 200 milliseconds.

The infrastructure that data teams built assumes data team consumers. The people actually building agents expect infrastructure that works like the APIs they're familiar with, not data warehousing tools that require specialized expertise.

Why Operations Change Everything

The moment agents are expected to take action, the underlying data model must change.

Data warehouses are built for analytical consumption. They centralize data, transform it for reporting, and help humans generate insights. Even with reverse-ETL pipelines that sync data back into operational tools, warehouses remain outside real-time decision loops. They move data, but they don’t own actions.

Agents remove that separation.

Instead of producing insights for humans to act on later, agents execute decisions directly. They resolve tickets, initiate refunds, update records, and trigger escalations in real time. These are operational actions with immediate impact on production systems.

That shift changes the infrastructure requirements. Analytical infrastructure falls short in this context.

Warehouses are optimized for aggregation, historical analysis, and tolerance for latency. Operational systems require something different:

Low-latency decisions
Strict access controls
Guarantees around correctness

Once agents operate inside transactional workflows, the system must support execution, not just analysis. Every action changes the system state and can trigger downstream processes across multiple tools. The infrastructure has to keep up.

This introduces constraints that analytical systems were never designed to handle. Actions must be governed, auditable, and reversible. When an agent updates a record or issues a refund, teams need visibility into the context used, the policies applied, and the reasoning behind the decision. Without this traceability, agents can't be trusted in production.

The answer isn't adding write capability to analytical stacks, but building infrastructure where entity-aware, real-time operations are first-class concerns from the start.

The New Architecture Pattern

Centralization still matters, but for a different reason. Agents need a shared understanding of entities across the business: which records refer to the same customer, how transactions connect to accounts, and how tickets relate to orders. Identity resolution and relationship mapping provide the foundation agents rely on to discover context and reason across systems.

In the warehouse era, centralization was the end goal. Data flowed into the warehouse to create a single source of truth for analysis. In the agentic era, centralization becomes one half of a continuous loop. Data is:

Centralized for alignment
Fetched or written in real-time for action

The centralized layer often lives in the warehouse. It remains the natural place to resolve identities, stitch records across systems, and model long-lived relationships, because it already aggregates data across time and sources. What changes is how it is used: the warehouse defines who an entity is and how it connects, but agents don’t rely on it for the current operational state. Live systems remain the source of truth for execution.

Real-time fetch powers action. When an agent needs current data about a specific entity, it fetches directly from source systems, not from a warehouse that synced hours ago. These fetches happen with proper authentication and permissions. They combine real-time data access with identity resolution to give agents fresh, accurate context for decision-making.

Write-back closes the loop. When agents act, those writes flow back to operational systems through controlled, auditable paths. Policies enforce what agents can modify. Every action is logged and reversible when needed.

Together, these capabilities let agents operate end-to-end. Agents discover which entities exist and how they connect, fetch fresh data on demand from live systems, and reason over that context to decide what to do. They then write results back safely to complete the action, and repeat the process as new context arrives.

What This Means for Leaders

Stop treating agents as another warehouse consumer. Agents need different infrastructure, one built around real-time fetch, entity-specific context, and write-back operations.

That means understanding the difference between analytical and operational access patterns. It means investing in real-time entity fetching directly from source systems and building governance for writes as first-class operations.

The teams building agents aren't data engineers managing complex ETL pipelines. They're software engineers who want to focus on agent logic rather than maintaining brittle connectors and integration infrastructure.

Those who build reliable agentic data infrastructure with proper connectors, entity resolution, real-time access, and governance will ship agents that actually work in production.

Subscribe to Agent Blueprint to learn more about agentic data infrastructure.