The copy tax: why business orchestration and automation need a zero-copy data layer

Most enterprise data isn't hard to reach. It's just been copied so many times that no one is sure which version is right.

Every architecture diagram tells the same story. A system of record on the left. An integration layer in the middle. A warehouse, a lakehouse, a cache, a sync, an event bus, a feature store on the right. Each box is there for a reason. Each one was the right answer to a problem at the time it was added. And each one is now a place where data has to be kept consistent with every other place.

That is the copy tax. Enterprises have been paying it for a decade, and most have decided it was worth paying because the alternative was no analytics at all. Business orchestration and automation changes that calculation. The moment data starts driving execution across agents, robots, workflows, and apps—not just feeding dashboards—the cost of stale data can show up in the work itself, not just the reporting.

Why the copy-and-sync model is reaching its limit

The copy pattern was built for a world where data moved on a schedule. Each night, extract, transform, and load (ETL) fed the warehouse. Hourly syncs refreshed the cache. Weekly extracts populated the lakehouse. Latency was measured in hours and tolerated, because the downstream consumer was a dashboard or a report—and dashboards refresh on a cadence.

Agents don't. Agents act.

When an agent decides whether to approve an invoice, route a claim, escalate a ticket, or recommend a credit line, it is making a decision the business will execute on. If the data underneath that decision is six hours old, the consequence is not a stale chart. The consequence is a wrong action—a missed payment window, a duplicate refund, a customer told they're ineligible for something they actually qualify for. The tolerance the enterprise had for ETL lag in analytics evaporates the moment data starts driving execution.

That is the architectural pressure point. The same data layer that comfortably served reporting cannot comfortably serve agents, robots, and workflows acting on the business in near real time. Something has to give.

What zero-copy actually means

Zero-copy connectivity is the architectural alternative to moving data every time you need to use it. Instead of replicating data from its source into another system, a zero-copy layer federates queries to the source at request time. The data stays where it lives. The consumer sees it as if it were local. This is distinct from in-platform zero-copy cloning and sharing features: nothing is duplicated and nothing is moved into UiPath.

This is not a new idea in data engineering. What is new is making it the foundation for how enterprise automation reaches data—not just how analytics queries it.

In UiPath Data Fabric, federated entities are the zero-copy primitive. An entity points at a live external system—Snowflake, Databricks, SAP, Salesforce, ServiceNow, an operational database—and federates queries to it on demand. Nothing is copied into UiPath. The entity is a model of how the data is shaped and how it relates to other entities, not a duplicate of the data itself.

And because a single entity can span more than one source system, agents and automations can query across them without anyone consolidating that data into one place first.

The practical effect is that an agent, a workflow, or an app querying a customer entity, an invoice entity, or an order entity is reading the source of truth in that moment. Not a snapshot. Not a cached copy. The current state.

The cost of copying, made concrete

It is easy to underestimate what the copy pattern actually costs an enterprise, because the costs are distributed across teams and budgets. Pulled together, they look like this:

• Reconciliation overhead. Every copy is a place where data can drift. Teams build pipelines to detect drift, jobs to fix it, dashboards to monitor it, and on-call rotations to respond when it breaks.

• Governance surface area. Every copy is another place where access policy, lineage, retention, and audit have to be enforced. The compliance team is implicitly being asked to govern N copies of the same data, with N growing.

• Integration rebuild. Every new use case that needs data from a system tends to build its own joins, transformations, and access paths. The same logic is rewritten across projects because there is no shared model to consume.

• Latency the business notices. By the time copied data is current enough to act on, the moment to act may have passed. For analytics, this was an inconvenience. For agents, it is a failure mode.

Zero-copy removes the source of these costs rather than mitigating them. There is no drift between the source and a copy if there is no copy. There is no governance surface for a duplicate that does not exist. There is no integration to rebuild if every consumer reads from the same federated entity.

The UiPath role in the zero-copy ecosystem

Zero-copy is not a UiPath invention, and we're not trying to replace the data platforms enterprises already trust. Snowflake and Databricks are where modern enterprises consolidate analytics, AI, and operational data. They are designed for that role and they are very good at it.

What enterprises have been missing is the layer that makes the data in those platforms—and in SAP, Salesforce, ServiceNow, and operational databases—directly usable by the automation that runs the business. Not via another copy. Not via another sync. As governed, structured context that agents and workflows consume in place and live or in near real time.

That is the role UiPath Data Fabric plays. Snowflake and Databricks remain the systems of record for the data they hold. UiPath becomes the zero-copy context layer that lets that data drive execution across agents, orchestration, apps, and automations on the UiPath Platform.

Data platforms hold the data. Data Fabric makes it usable by the automation that runs the business—without moving it.

What this means for the next generation of automation

The agents an enterprise will be running two years from now will not be the agents it is building today. The models will change. The frameworks will change. The connectors will change. What stays constant is the data and the systems that hold it.

That is the bet behind a zero-copy data layer. If the data stays where it lives and is modeled once as governed federated entities, every agent, workflow, and app built from here forward consumes the same trusted context. New use cases compose on top of the same foundation instead of rebuilding it. The data platforms enterprises already invested in keep their place. The copy tax stops compounding.

That is what zero-copy is for. Not avoiding data movement as an end in itself, but giving business orchestration and automation a data foundation that holds up at enterprise scale.

See how UiPath Data Fabric puts zero-copy to work—giving agents governed, live or near-real-time context across your enterprise systems.