When line-of-business software starts running inside your data platform, the choice in front of you stops being about data. It becomes a question about where your AI agents run, and who controls them.
Something shifted at this year’s big data conferences, and it didn’t get the attention it deserved. The data platform is turning into the place where the work actually happens, not just where the data sits and waits to be queried.
Bain’s read on the Databricks Data + AI Summit, published this week, said it plainly: enterprise AI is moving past agent demos into agent operations, and the Lakehouse is being repositioned as the place where agents do the work of the business, under governance. New releases put line-of-business software directly inside the governed data environment, and the platform’s agentic “coworker” is pitched as something that connects your data, documents, applications, and people in one place. Bain’s conclusion is the line worth holding onto: the more applications run inside the governed data environment, the more the data platform becomes an application platform by default.
That sounds like a data story. It isn’t. It’s a decision about where your AI agents will run, what they can reach, and whose runtime they answer to. And most organisations are about to make it without noticing.
What Actually Changed
For most of the last decade, the data platform had one job: bring information together so people could analyse it. Dashboards, notebooks, SQL warehouses, governance catalogues, all built around a human who would ask a question, read the answer, and decide what to do next. Agents break that model. They don’t just read data. They interpret context, call tools, write code, trigger workflows, and take action.
So the platforms are changing shape to hold them. Databricks now wraps agents in a governed context layer that hands them a machine-readable model of what the business’s data means, alongside an expanded catalog that governs access, cost, lineage, and identity in one place. Snowflake is making a similar move with its own context and governance work. None of it is subtle once you notice the direction: the vendors want your agents living inside their platform, sitting right next to your data.
This is roughly the bet Palantir made years ago with Foundry, binding data, business logic, and actions into a single governed model that applications and agents run against. The difference in 2026 is that every major data platform is making that same bet at once, and customers are signing up for it. Days ago, Zeta Global said it would rearchitect its entire Data Cloud on Palantir Foundry so its AI engine could act on a broader range of governed enterprise data. The pattern is now the strategy, not the exception.
Why This Is an AI Decision, Not a Data One
Here is the part that matters for anyone running an AI programme. When applications and agents move into the data platform, that platform stops being plumbing and becomes the runtime your agents live in. Where an agent runs is no longer an infrastructure detail buried in a renewal. It decides what the agent can see, how it is governed, what it costs to operate, and how hard it will be to move later.
That makes agent placement a first-order strategy question, and it belongs to whoever owns your AI roadmap, not the data team alone. The convenient answer – build every agent natively inside whichever data platform you already run – is also the one that quietly hands a single vendor control of your entire agentic future.
The Lock-In You Won’t See Until You Try to Leave
There is a real upside to running agents where the data lives. Less data movement. Simpler governance. One place to set policy. Bain is right that it can cut complexity, and for plenty of workloads that is exactly the trade you want. The same move also changes your procurement position, your security review, and your exit cost all at once, and the exit cost is the one nobody models in the business case.
An agent built on one platform’s context model, calling that platform’s tools, governed by that platform’s catalog, is not portable in any meaningful sense. Rewriting it for another environment is close to rebuilding it from scratch. If your agentic roadmap is becoming your competitive edge, and for a growing number of businesses it is, tying it wholesale to one vendor’s runtime is a strategic decision wearing the costume of a technical convenience. The smartest build-vs-buy plays of the past year all share one move: rent the capability where it pays, but keep the context that defines your business, and the agent logic that acts on it, in your own hands.
What Separates the Programmes That Scale
The evidence on what works is unusually clear. Databricks’ 2026 State of AI Agents study, drawn from more than 20,000 organisations, found that those with proper AI governance and data infrastructure in place pushed 12 times more projects into production than those without, and teams using evaluation tools moved nearly six times more. Gartner expects 40% of enterprise applications to embed task-specific agents by the end of 2026, up from under 5% a year earlier. The agents are coming into your estate either way. Whether they reach production depends on the foundations beneath them.
The organisations pulling ahead didn’t get there by picking the flashiest platform. They got there by deciding agent placement on purpose: which agents run inside the data platform because they are tightly bound to governed data, which run in their own orchestration layer because they need to reach across systems, and which workloads they refuse to lock in at all. Placement is a design choice, and the teams treating it as one are the teams getting agents past the pilot stage.
Questions to Settle Before You Commit
If you are putting agents anywhere near your data platform this year, a few questions are worth answering deliberately rather than by default:
- Where should each agent run? In-platform for work tightly bound to governed data, in your own orchestration for anything that spans systems. Decide per agent, not once for the whole estate.
- What does the exit cost? Before building natively on a platform’s context model and tools, price what it would take to move off it. If that number is alarming, treat it as a design constraint today, not a surprise later.
- Who owns the context layer? The model of what your data means is the asset every agent depends on. Keep it defined in a form you control, rather than buried inside one vendor’s runtime.
- How portable is the agent logic? Favour designs where the reasoning and the actions can be lifted into another environment without a full rewrite.
- Who is actually making this call? Agent placement is an AI strategy decision. If it is being settled inside a data-platform renewal, it is being made by the wrong people.
Q&A: Deciding Where Your Agents Should Run
Isn’t running agents inside our data platform simpler and safer?
Often, yes, for work that is tightly bound to governed data: less movement, one governance point, a clear audit trail. The trade is portability and an exit cost most teams never measure. It’s the right answer for some agents and the wrong default for all of them.
Does this mean we shouldn’t use platform-native agent tools at all?
No. They are genuinely strong where the work sits close to governed data, and ignoring them would be its own mistake. The point is to choose deliberately, workload by workload, rather than letting one platform quietly become the runtime for your entire agentic roadmap because it was the path of least resistance.
We’ve already standardised on one data platform. Are we locked in?
Partly, and that is fine if it was a decision rather than a drift. Map which agents are tied to that platform’s context model and tools, price the exit honestly, and keep your highest-value agent logic portable. Lock-in you have chosen and costed is manageable. Lock-in you have wandered into is not.
Who should own the decision about where agents run?
Whoever owns your AI strategy and architecture, working alongside the data team rather than leaving it to them. Placement determines cost, governance, and future flexibility, and those are strategy questions, not storage ones.
What’s the first practical step?
Inventory the agents you are planning, and for each one ask a single question: does it need to live next to governed data, or reach across systems? That one question sorts most of a roadmap into the right runtimes and shows you exactly where you are about to over-commit.
Working Through This With Vertex Agility
This decision – where your agents run, and how much of your future you tie to one platform’s runtime – is exactly the kind of call our AI Consultancy practice exists to get right. Most AI deployments are performance theatre. We integrate AI, from agentic systems to custom models, where it demonstrably pays back, and we will tell you directly when a platform-native shortcut would cost you more in lock-in than it saves in convenience.
Agent placement is an architecture decision, and architecture is where we start. We help you work out which agents belong inside your data platform, which need their own orchestration to reach across systems, and where to keep the context and the logic portable so a vendor’s roadmap never quietly becomes your ceiling. Our Data Consultancy practice supports that directly, building AI-ready data platforms with governance and lineage designed in from the start, so the foundation your agents run on is one you actually trust and control.
Because we work across Microsoft, AWS, Google, and Salesforce rather than for any one of them, the advice you get is built around your outcome, not a platform’s licence revenue.
If you want a clear read on whether your data and infrastructure are ready to put agents into production, and where you risk locking your AI roadmap into someone else’s runtime, our free AI Readiness Mini-Audit is a straight place to begin. For a deeper conversation about where your agents should live, get in touch with us below.