August 2026 Summaries

Business context is the organizational layer of rules, definitions, exclusions, fiscal calendars, and authoritative-source choices that enables people and AI systems to interpret raw data correctly. While technical context identifies where data is stored and semantic context explains what fields mean, business context determines how data should be applied within a company’s specific reporting and operational conventions. Without documented context, analysts and AI agents may generate technically valid queries but reach inconsistent or incorrect conclusions by using deprecated tables, inappropriate definitions, or missing exclusions. The article argues that model improvements alone cannot resolve this issue, because reliable AI depends on governed access to the same institutional knowledge experienced analysts use. Organizations can capture this knowledge through business metadata, governed data products, and an enterprise context layer that consistently supplies rules to dashboards, reports, and AI agents, improving accuracy, consistency, and auditability.

Data sovereignty governs the laws, jurisdictions, and controls affecting data, while related concepts such as residency, localization, privacy, and AI governance impose distinct requirements on where data is stored, processed, accessed, and used. As enterprise AI depends on data distributed across regions, clouds, and operational systems, organizations must design architectures that account for legal, contractual, geographic, and internal-policy constraints rather than treating all requirements as generic compliance issues. The discussion argues that centralized copying of data can create governance, security, maintenance, and regulatory challenges, and that governed access to data in its existing location is often preferable. This approach requires consistent identity management, metadata, policy enforcement, entitlements, observability, auditability, and workload placement across hybrid and multi-cloud environments. Architects are encouraged to identify which constraints apply to specific datasets, users, workloads, and locations, distinguish fixed obligations from legacy practices, and build systems that enable AI and applications to access distributed data reliably while preserving appropriate control over its movement and use.

Enterprise AI initiatives often struggle less with model selection than with providing models and agents secure, timely access to the distributed business data needed for meaningful answers. The piece advocates a federated data-access model that queries data in place across lakes, warehouses, and operational systems, reducing the cost, latency, and regulatory complications of copying all data into a central repository. It recommends applying consistent identity controls, row filters, column masking, and auditing through a unified query layer, while packaging curated data products with tested business definitions and metadata so AI systems can interpret data reliably. A proposed 90-day starting approach focuses on one owned use case, two to four data sources, identification of data that cannot move, deployment of federated querying and minimum governance controls, and use of a defined data product rather than raw catalogs. Centralization and ETL remain useful for workloads requiring locally stored, frequently reused data, but federation is presented as a flexible initial path for governed AI access.

Centralizing data in a warehouse or lakehouse improves access by placing tables in a shared storage environment, but it does not automatically integrate them because differing entity definitions, identifiers, metrics, and ownership can remain unresolved. The discussion identifies incomplete mergers and acquisitions, proliferation of SaaS applications, and unclear governance as common reasons centralized environments continue to function as silos, illustrated by customer records that use incompatible account IDs and email-based identifiers. It argues that meaningful integration requires shared definitions for entities such as customers and orders, common identifiers, accountable owners, reconciliation of source fields, and durable documentation of business context. Data federation combined with a semantic or context layer is presented as an alternative to copying every dataset, enabling governed queries across distributed systems while applying consistent metric and relationship definitions. The piece also contends that these practices are increasingly important for AI agents, which can otherwise reproduce the inconsistent answers produced by unreconciled data, and describes an Apache Iceberg-based lakehouse as a flexible foundation for storing core data while federating access to external sources.

Starburst has been named a finalist in SiliconANGLE’s 2026 TechForward Awards for AI-Optimized Data Platforms, recognizing technologies that demonstrate measurable customer impact. The company positions its platform as a way for enterprises to securely access, govern, and analyze data distributed across clouds, lakes, warehouses, databases, and other systems without requiring full data centralization. Starburst argues that this capability is increasingly important as organizations move AI initiatives into production and need trusted, governed data for models, analytics, and applications. The announcement cites customer examples including Lockheed Martin’s use of Starburst Enterprise in an intelligent factory initiative and Talkdesk’s reported improvements in Iceberg lakehouse query speed and reliability using Starburst Galaxy.

Conversational data agents often succeed in pilots but fail to scale because organizations lack a governed, continuously maintained layer of enterprise intelligence that combines accessible data with business meaning, rules, relationships, policies, and accountability. The proposed approach, developed by Starburst and Artefact, uses a “Connect, Organize, Activate, Improve” model: federating existing data and metadata without requiring centralization, organizing them into governed AI-ready data products, making those products available to analytics and approved AI agents, and continuously improving them through usage and feedback. Financial services illustrate the need, as terms such as “customer” can have valid but conflicting definitions across retail, commercial, wealth, compliance, and marketing functions; agents need role- and context-aware governance rather than a single universal answer. The operating model assigns business context ownership to domain leaders, translation into data products to data and AI architects, and versioning, auditing, and traceability to control teams, allowing certified intelligence to be reused across systems. Without these structures, AI outputs may be inconsistent, unexplained, and unaccountable, while organizations that begin with focused use cases and clear ownership can build trusted intelligence that scales as business needs and AI capabilities evolve.

Context engineering is presented as an architectural approach for enabling AI agents to use Snowflake data reliably by supplying governed business definitions, metadata, and access policies that raw warehouse tables alone may not convey. The discussion argues that while Snowflake provides scalable storage and compute, agents need a shared context layer to identify authoritative datasets, apply consistent KPI definitions, and enforce row- and column-level permissions. Rather than replacing Snowflake or requiring data migration, this layer can use federation to connect Snowflake with other systems, including data lakes and Iceberg tables, while delivering curated, governed data products to analysts and agents. The article also highlights the Model Context Protocol as a managed and observable mechanism for agent access, and recommends beginning with a limited pilot that defines key terms, applies centralized policies, packages reusable data products, and then expands the pattern across teams.

Amazon Athena provides serverless SQL access to data in Amazon S3, but its direct-query model does not supply AI agents with the business definitions, metadata, governance, or access policies needed to produce reliable answers. The article argues that context engineering, rather than prompt engineering alone, should create a governed semantic layer containing shared metric definitions, data-product metadata, lineage, version history, and centralized policies that ground agents before they query data. Such a layer can federate Athena with sources such as Snowflake and Redshift without requiring data migration, enabling agents to use consistent definitions across systems while limiting duplicated data. It also addresses Athena-specific concerns including pay-per-scan costs from exploratory agent queries, potential contention, and the lack of native auditability and policy portability. By adding explainability, traceability, and governed access over existing Athena workloads, organizations can support more dependable production AI agents without replacing their current data environment.

Effective AI data products require validation beyond successful SQL execution because technically valid outputs can still conflict with an organization’s business logic or omit important information. The guidance emphasizes using subject-matter experts to test products with real workplace questions, as these experts can assess both accuracy and completeness and identify unsupported use cases. When incorrect answers arise, teams should investigate product metadata, column descriptions, and view logic in that order, since unclear business definitions and field documentation are often more common causes than SQL defects. Metadata should be version controlled so past agent responses can be traced to the definitions in effect at the time, while governance and role-based access controls should be established before deployment to prevent overly broad exposure of sensitive data. The recommended process is iterative: build and document the product, test it with experts, correct failures, retest, define access controls, and retain versioned records of its logic.

A data warehouse is a specialized analytical database that uses technologies such as massively parallel processing and columnar storage to consolidate, transform, and analyze large volumes of structured and semi-structured data for business intelligence, reporting, and AI initiatives. Platforms including BigQuery, Snowflake, and Redshift commonly act as central sources of trusted data while integrating with data lakes, multi-cloud environments, and downstream analytics systems. Although loading data into warehouses is supported by mature ETL practices, extracting data can introduce significant egress costs, performance quotas, consistency and format issues, schema-evolution challenges, and governance risks when warehouse-level protections do not extend to exported data. Effective extraction strategies depend on the use case, ranging from native bulk exports for occasional transfers to APIs, federation, reverse ELT, and governed caching for frequent or operational workloads. The discussion recommends aligning compute and storage geographically, minimizing unnecessary data movement through pushdown capabilities, using fault-tolerant pipelines, and applying portable security controls such as private networking, identity federation, role-based access, and masking.

Iceberg tables can gradually lose performance and accumulate storage costs when maintenance is absent or no longer matches workload growth, with common symptoms including bloated metadata, proliferating small files and delete files, slower query planning and execution, and orphaned storage objects. The post describes Starburst Icehouse LakeOps as an automated, serverless maintenance service that addresses metadata growth by rewriting manifests, expiring obsolete snapshots, and removing dangling deletes; improves query performance through compaction that combines small files and incorporates deleted records into rewritten data files; and reclaims wasted storage by detecting and deleting orphaned files left behind by expired snapshots or failed operations. It argues that continuous, incremental maintenance can keep large Iceberg tables efficient and reliable without requiring teams to schedule jobs or manage clusters manually.

Amazon Redshift remains a strong AWS-native option for structured business intelligence, predictable reporting, and low-latency analytics, but centralizing all organizational data in it can introduce concurrency constraints, tuning and maintenance work, proprietary storage lock-in, data movement costs, and fragile ETL pipelines. The piece presents open lakehouse architectures based on Amazon S3 and Apache Iceberg as an alternative that keeps data in open formats while providing warehouse-like capabilities such as transactions, schema evolution, and time travel. It positions Starburst, built on Trino, as a federated query layer that can access and join data across S3, databases, cloud platforms, and SaaS sources without copying it into a central warehouse, while noting that its performance and cost comparisons with Redshift are vendor-stated and unverified. Rather than recommending a wholesale replacement, it advocates a hybrid approach in which Redshift supports refined, high-performance BI workloads and a lakehouse plus federation supports large-scale, semi-structured, cross-source, AI, and exploratory analytics.

Amazon Athena is presented as a serverless SQL query service for analyzing Amazon S3 and selected external data sources, offering simple setup and pay-per-scan pricing that can suit occasional exploratory queries. The discussion argues that its AWS Lambda-based federation model, multi-tenant infrastructure, scan-based charges, and limited external connector range may create inconsistent performance, unpredictable costs, and reduced flexibility for large-scale, high-concurrency, or multi-cloud workloads. It positions Starburst Galaxy and Starburst Enterprise, both based on Trino, as alternatives that provide dedicated compute, more than 50 native connectors, query pushdown, workload isolation, autoscaling, caching, and support for hybrid and multi-cloud data access. According to the source, Athena remains appropriate for low-volume workloads centered on S3, while organizations needing low-latency dashboards, broad cross-cloud federation, predictable resource management, and enterprise-scale analytics may consider platforms such as Starburst.

Query caching stores previously computed query results so later identical or compatible requests can avoid repeated scans and calculations, improving response times and reducing compute costs for dashboards, exploratory analytics, and AI or machine-learning pipelines. The approach can yield substantial gains for high-concurrency workloads and large data lakes, but using transient query-result caches as inputs to production ELT pipelines creates risks because caches may expire quickly, be user- or cluster-specific, have small size limits, and be invalidated by data changes or non-deterministic queries. Cache-based ingestion can also complicate governance, security, lineage, debugging, and cost forecasting because cached artifacts are ephemeral and may fall outside conventional data-management controls. The Starburst Team recommends purpose-built alternatives such as durable materialized views, transparent cached views and table-scan redirection, and data-level caching with indexes, alongside monitoring, refresh SLAs, and fallback mechanisms that recompute from source data when cached data is unavailable.

Starburst has introduced an OpenAPI connector, entering public preview with Starburst Enterprise 482, that lets users query data from APIs with OpenAPI descriptions through SQL without building custom pipelines or copying data manually. The connector creates catalogs from an API’s base URI and specification, automatically generating table functions for qualifying GET endpoints and translating JSON responses and schemas into Trino-native rows, columns, arrays, and row types. Users can join API data with information from Starburst’s existing connectors, analyze nested API responses using SQL features such as UNNEST, and configure authentication for private APIs. It also provides configurable cast policies to either drop unsupported schema elements or fall back to strings and JSON types, enabling partial access to complex APIs such as GitHub’s. Pagination support can follow link headers for multi-page results, though sequential pagination may affect performance for large datasets, while query limits can speed API exploration.

Data Products as Code (DPaC) is presented as a YAML-based approach for creating, documenting, versioning, and managing curated data products, intended to bridge the gap between manual UI-driven workflows and complex API-based coding. Starburst’s platform allows users to describe desired products in natural language, after which an AI agent can identify relevant data sources and generate editable YAML definitions containing metadata, datasets, SQL transformations, ownership, and business rules. The approach supports both human and AI consumers by adding explicit context such as business rules, certified “gold standard” questions, and AI-generated schema documentation. Through a CLI, these definitions can be exported to version-control systems and incorporated into GitOps and CI/CD workflows with validation, peer review, auditing, and automated deployment. AI agents may also identify recurring user queries or joins and propose new data products for human review. Underlying the model is Starburst’s Trino-based data federation capability, which enables products to combine data from lakes, warehouses, and other silos without centralizing it.

Snowflake’s consumption-based model can produce unpredictable costs as data volumes, AI workloads, and centralized storage grow, so organizations are advised to combine immediate operational controls with longer-term architectural changes. Recommended measures include right-sizing virtual warehouses, setting aggressive auto-suspend times, using multi-cluster capacity for variable concurrency, applying resource monitors and statement timeouts, and optimizing queries through partition pruning, clustering, and careful use of services such as materialized views and automatic clustering. The piece argues that cold, high-volume, or infrequently queried data may be less expensive to store in open lakehouse formats such as Apache Iceberg on Amazon S3, rather than maintaining it in Snowflake’s proprietary environment. It promotes a coexistence approach in which Snowflake remains available for high-value structured workloads while Starburst’s Trino-based platform federates queries across distributed sources and runs selected analytics workloads directly on open data. This architecture is presented as a way to reduce ingestion, storage duplication, and compute costs, support varied AI access patterns, and give organizations greater flexibility in selecting compute engines, although claimed Starburst savings of up to 65% are identified as vendor-stated and unverified.

Agentic AI expands enterprise governance challenges beyond data discovery and access by enabling software agents to take actions across distributed systems on behalf of users or services. The discussion argues that agents should be treated as distinct principals with explicit, traceable chains of identity and delegated authority, rather than inheriting broad user permissions or relying on long-lived service credentials. It recommends an “ephemeral token fabric” that issues short-lived, audience-bound, task-specific capabilities and continuously authorizes each step of an agent workflow using workload identity, token exchange, revocation, and proof-of-possession controls. Effective governance should combine role-based access control with attribute-based, context-aware policies covering purpose, data sensitivity, environment, action, and time constraints, while enforcing decisions close to the relevant data source, tool, API, or operational service. Because data, compute, models, and identity systems may span on-premises, cloud, and vendor-managed environments, organizations need portable policy semantics and audit trails that retain the initiating user, acting agent, tools, resources, and policy decisions across boundaries. Protocols such as MCP can facilitate tool use but do not independently solve authorization, making it necessary to prevent agents from exploiting broadly privileged connections and to preserve accountability throughout each action. The proposed model emphasizes unified identity, policy, lifecycle management, observability, revocable authority, and safe failure, enabling enterprises to grant agents precise permissions while explaining and controlling their behavior afterward.

Following SAP’s acquisition of Dremio, the piece advises customers to continue using existing deployments while assessing longer-term effects on product roadmaps, cross-platform connectivity, portability, governance, and AI workloads. It recommends asking whether promised features will remain funded, whether the platform can maintain native access to data outside the SAP ecosystem, whether table formats and catalogs preserve the ability to move workloads, and whether security policies, definitions, and audit trails apply consistently across all queried sources. It also emphasizes that AI agents need current, governed access to data across databases, warehouses, SaaS applications, and lakes to avoid producing confident conclusions from incomplete information. Rather than urging a full replacement of Dremio or rejecting SAP integration, the piece advocates selectively moving data when necessary and using a data-federation approach to provide access to distributed data while preserving existing investments and vendor flexibility.

Data virtualization creates a logical access layer that enables users to query and combine data across databases, warehouses, lakes, lakehouses, SaaS applications, and cloud environments without first relocating it, extending data federation with semantic abstraction, centralized governance, and security controls. It supports “read in place” analytics, real-time reporting, AI exploration, and data mesh or fabric architectures by making distributed sources appear more unified, while hybrid strategies can materialize high-value datasets into formats such as Iceberg or Delta Lake for demanding workloads. Its effectiveness is constrained by cross-source performance, network latency and egress costs, SQL and API differences, rate limits, inconsistent security models, limited cross-system transaction guarantees, and difficulties in monitoring and recovering distributed workflows. The recommended approach is incremental adoption, beginning with manageable ad hoc analytics use cases, then combining federation, caching, materialized views, governance integration, and observability based on workload needs rather than treating virtualization as a replacement for all data movement or ETL.

As enterprises shift from analyst-mediated business intelligence to AI agents and large language models that query data directly, the central challenge becomes preserving the institutional context analysts once supplied, such as approved metric definitions, reliable sources, business rules, and domain-specific interpretations. The proposed enterprise context layer is a governed functional tier between agents and data that provides structured metrics and logic, semantic relationships across disparate systems, and traceability and access controls for auditable answers. Unlike broad data catalogs that can expose agents to obsolete, temporary, or conflicting assets, it selectively presents steward-certified “gold” data products and metadata harvested from tools such as dbt, Tableau, catalogs, and query histories. Treating data products as code through version-controlled YAML definitions and CI/CD workflows can keep context aligned with changing data pipelines across distributed architectures. The layer can also improve over time by incorporating agent usage, human feedback, and steward corrections, with the goal of giving both people and AI systems a current, certified shared understanding of enterprise data.

As companies increasingly favor AI over traditional Business Intelligence (BI) dashboards, the shift is driven by the need for more dynamic, contextual, and rapid data analysis. AI provides the ability to engage in conversational analytics, allowing business users to ask ad hoc questions and receive immediate, context-rich answers, unlike the static nature of BI dashboards that often become obsolete due to the time taken to produce them. Despite AI's promise, success hinges on a robust data architecture that integrates data from various sources, enabling access to structured, unstructured, and semi-structured data. This transition involves overcoming challenges like AI's susceptibility to bias and hallucinations, and necessitates a federated data model and a well-defined governance framework. Starburst's enterprise intelligence platform exemplifies such a solution, offering data lakehouse technology to connect and manage data efficiently, thereby facilitating the transition to AI-enhanced decision-making.

In the evolving landscape of artificial intelligence, the text emphasizes the critical importance of context over merely relying on semantic layers to achieve accuracy in AI-driven decision-making and insights. Context encompasses the implicit knowledge a human possesses, such as fiscal calendars and business-specific definitions, which AI lacks unless explicitly provided. As AI models become commoditized and widely available, the differentiator shifts to how effectively an enterprise provides context to these models. The text outlines four types of context—technical, semantic, business, and operational—and introduces the concept of "context intelligence," which is essential for selecting, ranking, and applying the right context at query time. This context intelligence requires capabilities like resolution, schema linking, ranking, and attribution to ensure accuracy and adaptability. The text argues that while traditional semantic layers are necessary, they are insufficient for the dynamic and conversational nature of modern AI interfaces, which require a broader architecture that integrates governed context, a trust loop for continuous improvement, and the ability to self-heal and adapt as business environments change. This comprehensive approach, involving governed context and intelligence layers, ensures that AI systems not only provide accurate and relevant insights but also continuously evolve and improve over time.