There is a persistent fantasy in enterprise AI circles that the hard problem is the model. Pick the right foundation model, wire it to your data, and autonomous AI agents will start generating business value. AWS’s new multi-cloud lakehouse architecture post, the first in a four-part series, is a systematic dismantling of that fantasy. The hard problem is the data foundation, and most enterprises don’t have one that can support agentic AI at production scale.<\/p>\n
This is a deeply technical post dressed in architecture diagrams, but the strategic argument embedded in it deserves executive attention. AWS is making a specific bet: that the enterprise AI race will be won or lost at the data infrastructure layer, not the model layer, and that the organization best positioned to unify fragmented enterprise data environments will capture the agentic AI deployment wave. The blueprint they’ve published here is their answer to what that infrastructure looks like.<\/p>\n
The AWS post opens with an observation that every CIO and CDO knows is true but few have operationalized: enterprise data is not accidentally fragmented, it is deliberately fragmented. Relational databases for transactions, cloud data warehouses for analytics, object stores for unstructured data, SaaS platforms for domain functions. Each decision was rational at the time. The aggregate result is a heterogeneous landscape that is genuinely difficult to query coherently.<\/p>\n
Traditional analytics tools managed this by narrowing scope. A BI dashboard queries a specific warehouse. A data science team works from a curated feature store. The tool defines the perimeter of the data problem. Agentic AI systems break this pattern entirely. An AI agent reasoning autonomously about “why did revenue decline in the Northeast last quarter” needs customer records from an on-premises database, marketing spend data from a cloud analytics platform, sales pipeline data from Salesforce, and fulfillment data from an ERP system, simultaneously, with consistent governance applied across all of it, in real time.<\/p>\n
No enterprise data environment built for traditional analytics can serve that request today. This is not a minor gap. It is a structural incompatibility between how enterprise data has been architected and what agentic AI systems require to function. The post identifies this as the critical challenge: not AI capability, but data infrastructure readiness.<\/p>\n
The AWS solution is built around three integration patterns, and the sophistication of the post is in how clearly it articulates when to use each rather than pretending one approach fits all situations.<\/p>\n
The first pattern is catalog federation via the Iceberg REST API. If your data already lives in Iceberg format on S3-backed storage in platforms like Databricks or Snowflake Polaris, you can federate the metadata catalog into AWS Glue Data Catalog without moving the data. Queries run in place; the unified catalog makes the data discoverable to AI agents. This is the cleanest approach when it’s available, and the growing adoption of Apache Iceberg as an open table format standard is what makes it increasingly viable.<\/p>\n
The second pattern is query federation through connectors, targeting platforms like BigQuery, Azure SQL, and Salesforce that aren’t Iceberg-native. Data stays in the source system; queries cross cloud boundaries at execution time. The post is honest about the latency implications: this works well for moderate volumes, becomes non-deterministic at scale, and should be avoided for high-frequency AI agent workloads that can’t tolerate unpredictable response times.<\/p>\n
The third pattern is full ingestion: move the data to AWS via Zero-ETL integrations or ETL pipelines, store it as Iceberg tables, and query it natively. Higher upfront cost, highest performance and governance fidelity, and the right choice when AI agents are hammering the data at high concurrency or when full Lake Formation policy enforcement is required.<\/p>\n
Threading through all three patterns is a governance architecture built on AWS Lake Formation that applies fine-grained access control at the row, column, cell, and tag level, consistently, regardless of which integration pattern the underlying data uses. When an AI agent submits a query, Lake Formation enforces the permissions of the human user on whose behalf the agent is acting. This is the crucial insight: governance doesn’t get weaker because an AI agent is in the chain. It applies through the agent, not around it.<\/p>\n
Buried in the architecture walkthrough is something that deserves more prominent attention: the general availability of AWS Interconnect multicloud, announced in preview at re:Invent 2025 and now live. This is a managed service providing private, high-speed network connections between AWS and other cloud providers, starting with GCP and extending to Azure and Oracle Cloud Infrastructure later in 2026.<\/p>\n
The significance is straightforward. The default query federation approach routes cross-cloud queries over the public internet, which introduces latency variability, potential egress costs, and compliance exposure for organizations with data sovereignty requirements or regulations like HIPAA and PCI-DSS that prohibit data traversing public networks. Interconnect multicloud eliminates that constraint for GCP workloads today. For enterprises running meaningful workloads on both AWS and GCP, which includes a substantial portion of the Fortune 500, this changes the federation calculus significantly.<\/p>\n
The three-step provisioning process AWS describes, specify target cloud provider, select destination region, choose bandwidth, is designed to remove the friction that has historically made multi-cloud private connectivity a months-long networking project. Whether the operational reality matches the simplicity of the description will be revealed in production deployments, but the architectural intent is clearly to make cross-cloud private connectivity a configuration choice rather than an infrastructure project.<\/p>\n
Many architecture posts published by cloud vendors read as aspirational documentation for a system that works perfectly under ideal conditions. The AWS post is unusual in the quality of its production reality section, which deserves careful reading by any team planning an agentic AI deployment.<\/p>\n
The metadata drift problem is one that most teams discover expensively. Federated catalog entries go stale when source schemas change, AI agents generate SQL against columns that no longer exist, and the failures are silent rather than loud because syntactically valid queries return empty results rather than errors. The post’s recommendation to implement event-driven schema synchronization, where source systems push schema changes rather than waiting for scheduled crawlers to pull them, is the right architectural approach but requires source system cooperation that isn’t always achievable.<\/p>\n
The hallucination risk taxonomy is the most important section for any executive evaluating agentic AI for business-critical decisions. The post identifies three distinct failure modes: SQL generation errors where syntactically valid queries return semantically wrong answers, cross-source synthesis errors where results from multiple federated sources are incorrectly combined, and memory-augmented reasoning errors where historical context stored in the agent’s memory contaminates current query interpretation. Each of these failure modes produces outputs that look authoritative. A confident, formatted answer with the wrong revenue numbers is more dangerous than an error message, because it might be acted upon.<\/p>\n
The three-step validation framework the post proposes, source verification, reasonableness check, and cross-validation against a BI tool, is workable but adds latency and operational complexity that reduces the autonomous efficiency AI agents are supposed to deliver. The honest implication is that agentic AI on business-critical data requires human validation checkpoints for any output that informs significant decisions, at least until trust is established through demonstrated reliability over time. Teams that deploy without these guardrails will experience production incidents that set back organizational trust in the technology.<\/p>\n
The post includes a comparison of Amazon Bedrock AgentCore Gateway and AgentCore Runtime that seems technical but has direct operational consequences. AgentCore Gateway has a five-minute hard timeout. AgentCore Runtime supports fifteen-minute synchronous execution and eight-hour asynchronous execution.<\/p>\n
The practical implication: any AI agent querying large Iceberg tables, running federated queries across cloud boundaries, or executing complex multi-step analytical workflows will routinely exceed five minutes. The Gateway timeout isn’t a soft limit that can be tuned, it’s architectural. Using Gateway for these workloads doesn’t produce slow results, it produces failed agent invocations. The post’s recommendation to use Runtime for data processing jobs and Gateway only for lightweight metadata interactions is correct, but it requires architects to carefully classify every tool call in the agent workflow by expected execution duration, a discipline that prototype environments don’t enforce and production environments require.<\/p>\n
Near the end of the post, almost as an afterthought, is a description of the alternative architecture: rather than unifying catalogs centrally, let each data producer expose metadata and data through Model Context Protocol servers, and let the AI agent aggregate context at query time through a context layer.<\/p>\n
The post frames this as a fallback for organizations that face technical or political obstacles to catalog unification, which is accurate. But it undersells the architectural advantages. The MCP server approach gives data owners full autonomy over their data and metadata exposure without requiring cross-organizational governance negotiations. In large enterprises where different business units control different platforms and have different risk tolerances, the political barriers to unified catalog governance are often more significant than the technical ones. A federated MCP architecture accepts more operational coordination overhead in exchange for not requiring organizational consensus on a centralized governance model.<\/p>\n
For organizations with strong central data governance functions, the unified catalog approach is clearly superior. For organizations where data ownership is decentralized and politically contested, the MCP approach may be the only one that can actually be deployed, which makes it more than a fallback.<\/p>\n
The strategic message in this post, readable between the architecture diagrams, is that AWS is positioning its analytics stack, Glue Data Catalog, Lake Formation, Athena, Redshift, Bedrock AgentCore, as the unified control plane for enterprise AI that spans multiple clouds. The open Apache Iceberg standard is the interoperability hook that makes this non-imperialistic: AWS isn’t asking you to consolidate your data on AWS, it’s asking you to make your data Iceberg-compatible so AWS can govern and query it from wherever it lives.<\/p>\n
For CIOs and CDOs, the immediate action item is a data architecture audit framed around agentic AI readiness. Which data sources have well-defined metadata catalogs? Which are Iceberg-compatible? Which require query federation versus ingestion? Which governance gaps would be exposed when an AI agent starts querying across all of them simultaneously? Most enterprises have not done this analysis, and without it, any agentic AI deployment will surface data infrastructure problems at the worst possible moment: after the organizational commitment to deploy has already been made.<\/p>\n
For CISOs, the governance architecture described here, Lake Formation enforcement applied through AI agent queries, not around them, is the right model. The specific risk to pressure-test is the cross-source synthesis hallucination scenario. When an AI agent queries four different systems and synthesizes a recommendation, which system’s lineage records capture that synthesis? The post gestures at SageMaker Unified Studio data lineage for AI agent query auditing, but the completeness of that coverage in federated multi-cloud scenarios requires independent verification before any regulated-use-case deployment.<\/p>\n
For CFOs evaluating the economics, the federation versus ingestion tradeoff table in the post is genuinely useful. Federation has lower storage costs but higher per-query cross-cloud egress costs and non-deterministic performance. Ingestion has higher upfront costs but lower ongoing query costs and predictable performance. The right choice depends on query frequency and data volume, which means the economic analysis has to be done workload by workload rather than as a single architecture decision.<\/p>\n
AWS has published a serious, production-honest architecture guide for enterprises trying to build the data foundation that agentic AI requires. The technical recommendations are sound, the tradeoff analysis is unusually candid for vendor documentation, and the production lessons on hallucination risks and operational failure modes reflect genuine deployment experience rather than aspirational design.<\/p>\n
The strategic bet embedded in the architecture is that Apache Iceberg becomes the universal open table format standard, that multi-cloud private connectivity via services like Interconnect multicloud becomes the norm rather than the exception, and that AWS Glue Data Catalog and Lake Formation become the de facto governance control plane for enterprise AI spanning heterogeneous environments. Each of those bets is reasonable, though none is guaranteed.<\/p>\n
What’s not a bet is the underlying premise: enterprises that haven’t built a unified, governed data foundation cannot deploy agentic AI at production scale. They can run impressive demos. They can publish proof-of-concept results. But they cannot give AI agents the consistent, complete, governed access to enterprise data that autonomous reasoning requires. The organizations that recognize this now and invest in data infrastructure before the agentic AI wave hits production will have a durable advantage over those who try to retrofit governance onto a fragmented data landscape after the organizational commitment to deploy has already been made. That’s the real argument this post is making, and it’s correct.<\/p>\n