Should we just use the agent tooling in our warehouse?

If the work is analytical and stays inside one platform, yes — and it is usually the better choice. The data never moves, the governance catalogue you already maintain is enforced natively, and lineage comes for free rather than being reconstructed. Nothing bolted on from outside will beat that for questions answered entirely in SQL against tables that platform already governs.

Where do warehouse-native agents stop?

At the edge of the warehouse. The work that generates most of the value in an enterprise workflow is rarely confined to one platform: it reads from a warehouse, checks a ticket, updates a CRM record, and files a document. A warehouse-native agent can answer the first part precisely and cannot take the rest of the actions at all, because those systems are outside its execution and permission model.

Is a cross-platform agent less governed than a native one?

It does not have to be, but it has to earn what the native one inherits. Inside a warehouse, catalogue permissions and lineage are ambient. Outside it, identity federation, per-turn permission intersection, a write gate, and a trace that spans systems all have to be built explicitly. A cross-platform agent that does not do that work is genuinely less governed, which is why the honest comparison is against a platform that does it rather than against the category.

Warehouse-Native Agents and Where the Boundary Bites

Warehouse-native agents are good, and the reason is structural rather than a matter of implementation quality: they inherit governance instead of asserting it. The limitation is equally structural. They stop where the warehouse stops, and most enterprise work does not.

What living inside the data buys

Four things, and each of them is expensive to reproduce from outside. The data never moves, so there is no second copy to secure and no transfer for a reviewer to interrogate. The catalogue your data team already maintains is enforced natively, so an agent cannot reach a table its caller could not. Lineage exists as a property of the platform rather than something reconstructed after the fact. And there is no new perimeter, which means no new vendor in the security review.

From the standard

“Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.”

NIST SP 800-207, Zero Trust Architecture — csrc.nist.gov

If your use case is analytical and lives in one platform — a question answered in SQL against tables that platform governs — use the native tooling. It will be cheaper, it will clear review faster, and this page is telling you not to buy anything.

Where the boundary bites

Almost no enterprise workflow is confined to one system. A realistic one reads from the warehouse, checks whether a ticket already exists, updates a record in the CRM, and leaves a document somewhere a person will find it. A warehouse-native agent answers the first step precisely and cannot take the other three, because those systems sit outside its execution model and outside its permission model.

	Warehouse-native	Governed platform
Data movement	None	None, under BYOC
Catalogue permissions	Inherited	Intersected per turn
Lineage	Native	Built, and spans systems
Reach	One platform	Every approved system
Write gate	Platform-defined	Explicit: blast radius shown, replay refused
Portability	Tied to that vendor	Source transferred to you

Neither moves your data. They differ on reach, on the write, and on what you keep.

The second column is not automatically better. Everything in it has to be built, and a cross-platform agent that has not built it is genuinely less governed than a native one — which is the fair version of this comparison and the reason most cross-platform agent projects fail their review.

The concentration question

Native tooling deepens your commitment to one platform. That is often a reasonable trade — consolidation has real benefits and switching costs are already sunk. It is worth naming rather than absorbing silently, because agent logic written against one vendor's abstractions is the least portable code you will produce, and third-party concentration risk is a question regulators in several sectors now ask directly.

The arrangement that usually wins

Not one or the other. Let the warehouse do what it is good at — governed access to governed tables, with the catalogue enforced where it is already enforced — and put the cross-system work in a layer that federates identity, intersects permissions per turn, stops every write at a human gate, and emits one trace across all of it. The agent then reaches the warehouse as the person who asked, through the catalogue, rather than around it.

The test is the shape of the work, not the size of the company. Draw the systems one task touches. One box means use the native tooling and stop reading. More than one, with a write in any of them, means the coordination and the gate are the project — and the warehouse remains the right place for the data either way.

Axionalytics

Production agentic AI for enterprise engineering, data, and revenue teams.

Facing this in your own environment?

Forty-five minutes with the engineers who build these systems. Bring the constraint that has been blocking you — you will leave with an architecture opinion whether or not you work with us.