What Happened
Three AWS walkthroughs show how agents running on Amazon Bedrock AgentCore can query enterprise data through governed semantic layers rather than generating business logic directly against raw tables. The implementations use Denodo, Strategy Mosaic, or AtScale to expose metrics, relationships, and access controls through Model Context Protocol (MCP) tools. [1][2][3]
The architectural difference is where data is combined and queries execute:
- Denodo federates across operational, analytical, and on-premises systems. Its Customer 360 example combines Aurora, Redshift, and PostgreSQL through governed views, pushing work to individual sources where possible without maintaining an additional ETL-built table. [1]
- Strategy Mosaic links semantic models across sources. Its example combines Customer data in Aurora with Purchase data in Redshift, centralizing joins and metrics while pushing work to each source and combining aggregated results. [2]
- AtScale uses a warehouse-first approach. Operational data is replicated from Aurora into Redshift. AtScale executes queries against that single engine and can create warehouse-native aggregates for repeated workloads. Its semantic definitions are YAML-based and versioned in Git. [3]
These are architectural walkthroughs, not comparative benchmarks. They demonstrate integration patterns and governance checks, but do not establish relative cost, throughput, or production reliability. [1][2][3]
Why It Matters to Businesses
The important deployment decision is not just which LLM to use; it is where business meaning and authorization live. All three designs move reusable metrics and access rules into a governed layer shared by agents and other consumers. That reduces reliance on prompt instructions to define concepts such as lifetime customer spend or determine who may see sensitive fields. [1][2][3]
This also makes AI investment reusable. The same governed definitions can serve agents, BI tools, and applications through interfaces beyond MCP, although the supported interfaces differ by platform. [1][2][3]
The financial trade-off is less straightforward. Federation can avoid another persisted dataset, but it does not eliminate query compute, network traffic, or load on source systems. Warehouse-first execution introduces ingestion and storage costs, while providing a single execution environment and opportunities to accelerate recurring queries. The better choice depends on freshness requirements, source capacity, query repetition, and existing data infrastructure.
Kimbodo Engineering Perspective
Choose the execution model before the agent framework
We would favor federation when a bounded workflow needs data from several systems and consolidating it would delay delivery or violate freshness requirements. Denodo’s example illustrates this flexibility, including access to on-premises PostgreSQL. However, cross-source joins need realistic testing: selective queries may push down efficiently, while broad comparisons can require substantial data movement. [1]
We would favor warehouse-first execution when the organization already maintains a reliable analytical warehouse, recurring questions dominate, and operational databases should be isolated from agent-generated demand. AtScale’s single-engine execution and warehouse-native aggregates fit that pattern, but the answers remain dependent on upstream replication freshness. [3]
Treat governance as infrastructure, not prompt engineering
Semantic models constrain available definitions; they do not guarantee that an agent chooses the right metric, filter, or time period. We would test both the returned answer and the query interpretation. Likewise, read-only tools reduce mutation risk but do not prevent excessive queries or inappropriate disclosure.
User-specific identity is essential. Denodo’s example exchanges the user token for a Denodo-audience token; Mosaic carries user-specific OAuth identity into its authorization checks; AtScale applies caller policies through its AgentCore integration. A shared privileged service identity would undermine those controls. [1][2][3]
How We Would Implement It
1. Define a narrow, testable workflow
Start with one disputed business metric, two or three relevant sources where needed, and three to five acceptance questions. Include single-source questions, a cross-domain question, and negative authorization tests. This follows the incremental approach recommended in the Denodo and Mosaic walkthroughs. [1][2]
2. Establish the data and identity paths
Use the following logical path: authenticated user, application, AgentCore-hosted agent, approved MCP tools, semantic layer, and data engines. For federation, verify source connectivity, pushdown behavior, and cross-source transfer. For warehouse-first deployment, establish replication monitoring and define the maximum acceptable data age before exposing the model.
Preserve user identity through the tool boundary and enforce authorization in the semantic layer. Test denied access as carefully as successful access, including restricted fields and rows under different roles. [1][2][3]
3. Deploy contracts, not just prompts
Version metric definitions, model relationships, tool descriptions, and evaluation cases together. AtScale explicitly supports Git-versioned SML; for other platforms, we would establish an equivalent review and promotion process using their supported deployment mechanisms. [3] Restrict the agent to approved read-only tools, and enforce query timeouts, result-size limits, and concurrency controls outside the model.
4. Measure the complete request
Trace identity, tool selection, semantic query, generated SQL, source execution, and answer generation. Track end-to-end latency, query failures, source load, model-token consumption, and cost per successful task. AtScale’s documented logs include caller, policies, SQL, and aggregate use; confirm comparable visibility during any platform evaluation. [3]
Risks, Costs and Security
- Source-system contention: Federated queries can compete with transactional workloads. Apply workload limits and validate behavior during peak business activity.
- Freshness and consistency: Live federation does not inherently produce a transactionally consistent snapshot across systems. Warehouse replication introduces a different risk: stale answers. Define acceptable behavior for both.
- Authorization gaps: Test token audience validation, role mapping, and policy behavior across every enabled interface—not only MCP. The examples expose semantic models through multiple protocols. [1][2][3]
- Sensitive output retention: Field masking does not protect data already authorized for retrieval. Minimize what reaches model context, traces, logs, and caches; partition caches by authorization context where necessary.
- Total operating cost: Budget for platform licensing, model inference, AgentCore, database compute, networking, replication or aggregate storage, and operations. Self-managed Denodo and the illustrated AtScale EKS deployment also require infrastructure lifecycle management. [1][3]
Our recommendation: select the execution model using representative workloads and authorization tests, then choose the platform. A convincing demonstration is insufficient; the production gate should be correct answers, enforceable access, acceptable source impact, and measurable cost per completed business task.
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Infrastructure & MLOps practice, or Estimate My Infrastructure.
