Over the last two years, organizations have invested heavily in AI. They’ve licensed models, built internal agent teams, and launched pilots across IT, customer support, finance, and sales. In many cases, the agents work. By work, I mean they answer simple questions, generate content, and complete basic workflows.
But when companies try to scale AI across business processes, things start to wobble. The model isn’t to blame. The data architecture underneath it is.
The pre-AI assumption
Most enterprise data infrastructure was built on a very comfortable premise: data pipelines are relatively stable.
You build an ETL workflow to support reporting. You refine it, maintain it, and run it on a schedule. The costs are predictable because change is rare. Everyone’s happy. Or at least no one is shouting.
In a world where data primarily flowed into dashboards and warehouse queries, that model worked pretty well.
But AI and AI agents do not live in that world.
Agents do more than analyze data. They act on it. They trigger workflows across systems. So they need structured and unstructured context on demand. They live in a world where new use cases pop up every Tuesday, not once a year.
That acceleration requires data pipelines to turn from static infrastructure into a dynamic operational system. Legacy integration tools, already on their last legs, don’t survive this kind of shift.
Why legacy ETL becomes a liability
Traditional ETL platforms were not built for constant pipeline creation and iteration. Spinning up a new pipeline can take weeks. Each transformation step adds complexity. Costs often hinge on row-by-row processing or worker infrastructure that becomes increasingly unpredictable as workloads expand.
When pipeline demand was steady, this was tolerable.
But as AI spreads across departments, the number of required data flows multiplies. Each new agent use case introduces new joins, transformations, sources, and governance considerations. What used to be a static reporting pipeline becomes a constantly evolving web of operational data movement.
Integration teams respond the only way they can: stitching together tools. One for data movement, another for transformation, another for agent development, and a bit of Python to duct tape it together.
Velocity drops, costs climb, and complexity compounds. It’s architectural friction at its worst.
AI changes what data engineering must support
Here’s the uncomfortable bit: AI fundamentally changes the requirements of data engineering.
Data engineering can no longer sit politely downstream, preparing datasets on its own timeline. It has to operate inside the execution layer.
Agent-driven workloads demand:
- In-flight reshaping and joining of data across formats
- The ability to process large datasets in a single operation, not step-by-step iteration
- Cost models that remain predictable as use cases expand
- Tight coupling between data transformation and agent orchestration
- Governance and observability are embedded directly into the execution layer
In other words, the boundary between “integration” and “intelligence” collapses.
When data preparation and agent development live in separate stacks, organizations create the very bottlenecks they’re trying to eliminate with AI.
From reporting pipelines to operational pipelines
The enterprises pulling ahead in the agent era aren’t doing so because they chose better models. They’re winning because they chose to modernize their data architecture to match the operational nature of AI.
That means reducing the distance between raw data and intelligent action, and treating pipelines as part of business execution, not background reporting infrastructure.
And ultimately, it demands unifying data transformation and agent orchestration in a single environment built for speed, cost predictability, and scale.
At Tray.ai, that’s why we introduced Data Engineering within our AI Orchestration platform.
The new SQL Transformer allows teams to reshape, join, and transform bulk data in-flight using ANSI SQL directly inside their automation workflows. Instead of relying on bolt-on ETL systems or external worker infrastructure, transformation happens within the same execution layer as agent orchestration.
Engineered data can flow directly into Tray Agents’ knowledge stores or onward to Snowflake, Databricks, BigQuery, or Redshift through native connectors, all within a single, unified pipeline from raw data to intelligent action.
Remember…intelligence scales. Infrastructure has to keep up.
Go deeper and check out our Tray First Look session where we show how Tray Data Engineering solves the AI supply chain bottleneck that causes 60% of AI projects to fail.
