The Data Platform Is Becoming Invisible. The Control Plane Is Not.

Why simpler access to enterprise data requires stronger identity, semantics, policy, cost control, and evidence

For years, data platforms competed around familiar questions.

• How much data can we store?
• How fast can we query it?
• How cheaply can we process it?

Those questions still matter. But they are no longer the most interesting ones. A more important question is emerging:

How much complexity can the platform remove from the user without losing control underneath?

Several developments between 3 and 10 October 2026 have one thing in common.

Google introduced a work agent designed to operate across enterprise applications and data platforms. AWS made prepared analytical results reusable through Apache Iceberg. Snowflake and Databricks expanded direct access to Workday data without another permanent analytical copy. Databricks Apps can now work with the signed-in user’s existing data permissions. Snowflake agents can execute analytical code, while Databricks is adding runtime policies around AI models and tools.

These are different products solving different problems. But the direction is surprisingly consistent.

The platform is becoming less visible to the user.
The control layer underneath is becoming more important.

And there is an important distinction here. The infrastructure is not disappearing. Ideally, users simply need to think about it less.

The platform is moving behind the work

Google’s new Gemini agent is one of the clearest examples. Google describes a universal agent for work that can operate across collaboration applications, enterprise systems, and data platforms. Its new data and analytics capabilities are intended to let users ask questions in normal language while the system identifies datasets, generates SQL, Spark, or Python, and performs analysis. Source: Google Cloud — Gemini at Work 2026: Introducing the Gemini agent

The direction is easy to understand.

Today:

user → tool → analyst → platform → result

The intended future experience is closer to:

user → desired outcome → agent → governed systems → result

The user no longer needs to decide which database or analytical interface should answer the question. That is genuine simplification. But notice what has happened. The complexity did not disappear. The decision about which data, tool, model, or action to use simply moved somewhere else.

The agent and the platform underneath now need to understand:

• identity;
• permissions;
• source quality;
• business definitions;
• tool authority;
• cost;
• auditability.

Google’s own announcement emphasizes identity, authorization, policy, sandboxing and governance alongside the agent capabilities. That is not incidental. The more invisible the infrastructure becomes to the user, the more disciplined it needs to become underneath.

“Zero-copy” solves a real problem — but not every problem

Snowflake and Databricks both expanded direct access to Workday data during the week.

Snowflake’s generally available integration lets organizations query Workday Data Cloud tables directly without building another ETL pipeline or maintaining another persistent Snowflake copy. Workday remains the system of record, and Snowflake contacts Workday when a query runs.

Source: Snowflake — Workday Data Cloud zero-copy integration GA

Databricks’ beta Workday Data Connect federation follows a similar principle. Unity Catalog reads Workday’s shared Iceberg tables directly from Workday-managed storage. Databricks compute runs the queries, while Unity Catalog applies permissions and lineage.

Source: Databricks — Workday Data Connect federation in Unity Catalog

This is useful. Finance and workforce information is exactly the kind of data enterprises repeatedly extract, duplicate, and synchronize. If a team only needs the current authoritative state, another copy may add more operational work than business value. But “zero-copy” can easily become a slogan.

It does not mean:

• zero compute;
• zero network dependency;
• zero latency;
• zero source-system dependency;
• zero governance effort;
• zero need for historical data.

Valid reasons to copy data exist. Historical snapshots are one. Very high analytical volumes may be another. Regulatory isolation, resilience, predictable latency, or independent processing can also justify ingestion.

Databricks itself distinguishes three Workday access patterns: durable ingestion, catalog federation, and live query. Each exists because different business requirements need different architecture.

So the useful architectural principle is not: Never copy data.

It is: Do not copy data unless the copy solves a real requirement.

That is a much harder rule to market. It is also a much better one to design systems around.

Open data is not yet the same as an open architecture

AWS introduced another piece of this picture. Amazon Redshift can now create materialized analytical results as Apache Iceberg tables. A complex calculation can be executed once and its result stored in Amazon S3 as an Iceberg table that other compatible engines can query.

Source: AWS — Amazon Redshift adds Apache Iceberg materialized views

That gives us a useful progression: raw data shared openly

becomes: prepared analytical result shared openly

This matters.

If an expensive calculation has already been built, tested and approved, rebuilding another version for every analytical engine wastes both compute and governance effort.

The better model can be:

calculate once → govern once → reuse many times

But the word open still needs scrutiny. Refresh behavior matters.

Redshift can incrementally refresh eligible Iceberg materialized views. For Iceberg materialized views, incremental refresh currently supports only COUNT and SUM aggregate functions; other aggregates such as MIN, MAX and AVG require full refresh. External modifications and some snapshot conditions can also force full recomputation.

Redshift also supports automatic refresh for materialized views in supported configurations, so refresh should not be described as manual-only. The architecture still needs testing for freshness, workload priority, and total refresh cost.

Sources:
AWS — Refreshing a materialized view
AWS — REFRESH MATERIALIZED VIEW and Iceberg-specific behaviour

More importantly, an open file format does not automatically make the complete architecture portable.

The files may be open while:

• catalog ownership;
• permissions;
• lineage;
• policy;
• semantics;
• operational behaviour

remain platform-specific.

Databricks’ workaround for Iceberg REGISTER and UNREGISTER exposes exactly this next problem.

The model is intended to let catalog responsibility for a table move without moving the underlying files. UNREGISTER lets the old catalog explicitly relinquish responsibility before another catalog takes over, helping avoid split-brain ownership.

Source: Databricks — Preventing catalog lock-in with REGISTER and UNREGISTER

That leads to a more demanding definition of openness:

open storage → open tables → portable metadata → portable governance

The market is moving in that direction. It is not there yet.

Identity may matter more than the application

One of the week's least dramatic releases may have one of the largest architectural consequences.

Databricks made on-behalf-of-user authorization generally available for Databricks Apps. Instead of giving an application broad platform access and asking it to reconstruct the user’s permissions, the application can perform supported actions under the signed-in user’s identity.

Unity Catalog continues enforcing the user’s existing permissions, including row filters and column masks.

The application’s API scopes impose another boundary on what it can do.

Source: Databricks — Permission-aware Apps with on-behalf-of-user authorization

The model becomes:

User permissions ∩ Application scope = Allowed action

That is cleaner than:

Application gets broad access → application recreates authorization

It can reduce duplicated security logic and make governed internal applications easier to build. But there is an important caveat. A human’s existing access is not necessarily the right access for an autonomous application or agent. Many users already have broader permissions than they need for any individual task. For increasingly autonomous systems, the better model may therefore be:

human access ≥ application access ≥ task-specific agent access

A person’s authority should not automatically become an agent’s authority. Reusing identity is useful. Copying authority blindly is not.

Agent capability is advancing faster than authority models

Snowflake made Cortex Agent code execution generally available. An agent can generate and run code during a conversation to process information, perform calculations, and create visualizations. By default, the execution environment is isolated and has access only to information available in the current agent session.

Source: Snowflake — Cortex Agent code execution GA

This makes agents substantially more useful. It also makes the distinction between capability and authority more important.

Databricks is moving policy into the execution path through Unity Gateway service policies. Those policies can govern interactions with AI models and Model Context Protocol services based on request and response content and on who is making the call. Built-in, custom, and external policies can enforce guardrails.

Source: Databricks — Service policies for AI securables

On 9 October, Databricks also added request tags to Unity Gateway policy evaluation. A request can carry context such as:

project = chatbot
team = finance
environment = production

Policies can evaluate those tags, while the same metadata is recorded in usage tracking and inference tables for cost attribution and analytics.

Sources:
Databricks — October 2026 platform releases
Databricks — Request tagging

This is a small technical feature with a larger architectural implication.

Governance can move from: Who is calling?

toward: Who is calling, for what project, in which environment, using which tool, under which policy?

That is much closer to the level of context autonomous systems require.

But every control creates another dependency

Runtime guardrails sound inherently safer. Sometimes they are. They also create new architecture.

Databricks’ external service policies can use third-party guardrail providers as part of the decision path. That means the security layer itself becomes another component that needs to be reviewed for:

• confidentiality;
• residency;
• network exposure;
• latency;
• availability;
• contractual handling of data;
• cost.

Source: Databricks — Service policies and external guardrails

Get Oleg Gavrylenko’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This reveals a broader lesson: No free governance layer.

Every control reduces one class of risk while potentially adding another dependency. Good architecture makes that trade-off explicit.

A stronger control plane can also become a larger failure domain

There is another issue worth confronting. If you centralize more identity, permissions, models, tools, semantics, policy, and cost controls into one control plane, that control plane becomes critical infrastructure. Centralization can improve consistency. It can also increase blast radius.

A configuration mistake may affect many applications at once. A control-plane outage may block otherwise healthy workloads. A proprietary governance layer may become the next form of lock-in even when the underlying data uses an open format.

So the future should not simply be: Centralize everything.

A healthier objective is:

Centralize policy where consistency matters, but preserve clear boundaries, portability and failure isolation.

That is harder. But it avoids replacing data lock-in with governance lock-in.

Governance and correctness are not the same problem

This distinction is especially important for AI. An agent can be perfectly governed and still be wrong. It may:

• access only permitted data;
• use an approved model;
• remain within budget;
• call only approved tools;
• produce a complete audit trail;

and still reach the wrong conclusion.

Snowflake’s new Snowflake Decision private preview illustrates where the market may go next. The model can evaluate text or structured data against user-defined questions and return classifications, scores and probabilities that applications can use to choose between automated action, fallback or human review.

Source: Snowflake — Snowflake Decision with AI_COMPLETE

That is a more controlled pattern than: AI output → action

A better flow is: AI output → probability/confidence → policy → action or human review

But even here, you still need care. A model saying it is 95% confident does not prove that it is correct 95% of the time. Confidence is not automatically calibrated evidence. Before probabilities influence consequential workflows, organizations need to test whether those probabilities correlate with actual correctness in their own domain. This is why enterprise AI governance eventually becomes an evidence problem, not only an access-control problem.

Business meaning is moving into infrastructure

The control plane also needs to know what the data means. Databricks made window measures in Metric Views generally available during October. Calculations such as running totals, moving averages, and period-over-period changes can increasingly be defined centrally rather than independently inside every dashboard.

Source: Databricks — October 2026 platform releases

At first glance, this is a small analytics feature. Architecturally, it represents something larger.

Business meaning is becoming reusable infrastructure.

That matters because the same definition may now be consumed by:

• dashboards;
• applications;
• analysts;
• AI assistants;
• autonomous agents.

If “active customer” has five definitions, AI will not fix the problem. It will simply make the inconsistency easier to access.

The business user does not really want a data platform

This may be the most important conclusion. Most business users do not want a better data platform. They want the platform to get out of the way.

They want to say:

• Explain why margin changed.
• Show me the current workforce position.
• Compare this month with last month.
• Find the customer risk.
• Prepare the decision.

They do not want to decide:

• which database;
• which catalog;
• which engine;
• which model;
• which connector;
• which copy.

But they still expect the answer to respect:

• permissions;
• trusted definitions;
• privacy;
• quality;
• cost;
• evidence.

That is the actual challenge. The visible platform should matter less. The invisible discipline underneath must become stronger.

Simplicity is not the absence of complexity

This week’s announcements can easily be read as architecture disappearing. It is not. Complexity is moving.

• ETL complexity → federation governance
• Application authorization → identity propagation
• Dashboard calculations → semantic infrastructure
• AI prompts → runtime policy
• Model selection → routing and cost control
• Data copies → source-system dependency
• Agent capability → authority management

The platforms that succeed will not be those that pretend this complexity has vanished. They will be the ones that manage it well enough that users do not have to. That is a much better definition of simplicity.

What I would test now

I would not begin with another large platform transformation. I would choose one real business question.

Use:

• one authoritative source;
• one governed business definition;
• one permission-aware application or agent;
• one explicit cost boundary;
• one evidence trail.

Then test the happy path. After that, deliberately test the failures. Use another identity. Ask for restricted information. Remove the guardrail service. Change the business definition. Make the federated source unavailable. Ask the AI to decide when its evidence is weak.

A useful platform should prove more than: It produced an answer.

It should prove:

• The answer is sufficiently correct.
• The source is trusted.
• The meaning is consistent.
• The authority is appropriate.
• The cost is visible.
• The evidence is traceable.
• The prohibited action stops.
• Failure is understandable.

If we cannot demonstrate those properties, the interface may be simpler, but the system is not yet more trustworthy.

Conclusion

A universal work agent. Zero-copy SaaS data. Open analytical results. Permission-aware applications. Agent code execution. Runtime guardrails. These look like separate product announcements.

They are not. They all respond to the same pressure.

Enterprise users want the value of data without operating the infrastructure behind it.

That is a reasonable expectation. Meeting it safely takes more than another faster database. It requires identity that travels. Business meaning that is reusable. Policies that operate at runtime. Costs that remain attributable. Evidence that survives automation. And controls that do not themselves become an unmanageable source of dependency or lock-in. So the data platform may indeed become increasingly invisible to its users. The control plane should not disappear with it.

In fact:

The less the user needs to see the platform, the more disciplined the platform underneath must become.

Sources

Google Cloud

Gemini at Work 2026: Introducing the Gemini agent
Open source

Amazon Web Services

Amazon Redshift adds support for Apache Iceberg materialized views
Open source

Refreshing a materialized view — Amazon Redshift
Open source

REFRESH MATERIALIZED VIEW — Iceberg-specific behavior
Open source

Snowflake

Workday Data Cloud zero-copy integration — General Availability
Open source

Cortex Agent code execution tool — General Availability
Open source

Snowflake Decision with AI_COMPLETE — Private Preview
Open source

Databricks

Workday Data Connect federation in Unity Catalog
Open source

Permission-aware Databricks Apps with on-behalf-of-user authorization
Open source

Service policies for AI securables
Open source

October 2026 platform release notes
Open source

Request tagging for Unity Gateway
Open source

Preventing catalog lock-in with REGISTER and UNREGISTER
Open source