All systems operational
Details
  • Websitechecked 15s ago
  • Client portalchecked 15s ago
  • AI agentschecked 15s ago
  • Signals enginechecked 15s ago
  • Paymentschecked 15s ago
  • Email & reportschecked 15s ago
  • Scheduled jobschecked 15s ago

Open the status page

Faida Workforce · AI that Works AI that Works →

Why Your AI Agents Need a Semantic Layer, Not Just a Prompt

The Shift from Chatbots to Autonomous Agents

For the past two years, most organizations have treated generative AI as a conversational interface. The value proposition was simple: ask a question in natural language, get an answer. However, as businesses begin to deploy agentic AI—systems that don’t just answer questions but take actions like querying databases, updating records, or triggering workflows—the risks of this approach become apparent.

When an LLM writes a SQL query directly from a prompt, it is guessing at the structure of your data. It does not inherently know which columns are sensitive, how revenue should be calculated, or whether the user has permission to see specific customer records. This creates a governance gap. If you rely on the prompt to define these rules, you are asking a probabilistic model to perform deterministic security checks. It cannot.

Refer & earn: 30% of a client’s first month, then 10% of every month after that, for up to 24 months per client. See the partner programme →

A new architectural pattern emerging on Amazon Web Services (AWS) addresses this by decoupling the agent’s intent from the data’s reality. By placing a semantic layer between the AI agent and the underlying database, enterprises can enforce consistent definitions, row-level security, and audit trails without modifying the agent’s core logic. This post examines a recent implementation using AtScale and Amazon Bedrock AgentCore, illustrating why this separation is critical for enterprise-grade AI.

The Problem with Direct Database Access

In a typical direct-access setup, an AI agent connects to a data warehouse (such as Amazon Redshift) and generates SQL queries on the fly. While flexible, this approach suffers from three major flaws:

  1. Inconsistent Definitions: One agent might calculate “lifetime spend” as the sum of all orders, while another excludes refunds. Without a centralized definition, business leaders cannot trust the answers.
  2. Security Risks: Granting an agent direct SQL access often requires broad permissions. Ensuring that an agent only returns data relevant to the current user (row-level security) is difficult to enforce dynamically within the prompt itself.
  3. Lack of Auditability: When an agent makes a decision based on data, tracing exactly which metrics were used and who authorized the query becomes complex if the logic is embedded in the prompt rather than a governed model.

The solution is to treat data access as a service, not a raw connection. A semantic layer acts as a unified interface that translates natural language requests into precise, governed SQL queries. It ensures that every query, whether generated by a human analyst or an AI agent, uses the same business logic and security policies.

How the New AWS Architecture Works

A recent technical walkthrough published by AWS Machine Learning details a “Customer 360” pattern that integrates AtScale (a semantic modeling platform) with Amazon Bedrock AgentCore. This architecture demonstrates how to build a governed environment for agentic AI. The key innovation is the use of the Model Context Protocol (MCP) to connect the agent to the semantic layer.

1. The Inbound Path: Identity and Intent

The process begins when a client sends a request to the Strands agent hosted on Amazon Bedrock AgentCore. Crucially, the system validates the user’s identity via a JSON Web Token (JWT) against the enterprise identity provider before the agent even sees the question. This ensures that the agent knows who is asking, which is essential for downstream security enforcement.

The agent then uses a foundation model (such as Anthropic Claude Sonnet 4.6) to interpret the user’s intent and plan the necessary data retrieval. Instead of writing SQL directly, the agent decides to invoke a tool call to the AtScale MCP server.

2. The Outbound Path: Governance and Execution

This is where the semantic layer adds value. The AtScale MCP server acts as a proxy registered on AgentCore Gateway. When the agent sends its tool call, the gateway injects the user’s credentials. AtScale then resolves these credentials to a specific role, applying row and column filters automatically.

AtScale plans the query against a dimensional model defined in its Semantic Modeling Language (SML). This model is version-controlled in Git and exposed over multiple protocols, including SQL and XML for Analysis (XMLA). The resulting SQL is pushed down to Amazon Redshift Serverless for execution. Because the joins, metric definitions, and security filters live inside the semantic layer—not the prompt—the agent receives a consistent, secure, and auditable result.

3. The Data Model: Dimensions and Measures

The example uses a retail “Customer 360” scenario involving customer profiles, orders, products, and rewards enrollments. The semantic model maps these entities into a star schema:

  • Dimensions: Customer, Product, Date, Vendor, and Rewards. These define the categories of analysis.
  • Facts: Purchase transactions.
  • Measures: Calculated metrics such as total_revenue, order_count, and units_sold.
  • Calculated Measures: Business logic like customer_lifetime_value and spend_tier, which are evaluated at query time.

By defining these elements in YAML files within Git, data engineers can review changes via pull requests. This brings software development best practices to data modeling, ensuring that any change to a metric definition is tracked and approved before it affects AI agents or BI tools.

What This Means for Business Leaders

The adoption of semantic layers for agentic AI is not just a technical preference; it is a strategic necessity for scaling AI safely. Here is what this shift means for organizations:

Consistency Across Tools

Because the semantic layer exposes the same model over SQL, XMLA, and MCP, both human analysts using traditional BI tools and AI agents get the same computed answers. This eliminates the “single source of truth” problem where different departments report conflicting numbers because they use different calculation methods.

Reduced Development Friction

Data engineers no longer need to write custom connectors for every new AI application. By standardizing on a semantic layer, they can onboard new agents quickly. The agent simply needs to know how to talk to the MCP server, not how to navigate the underlying database schema.

Enhanced Security Posture

Security is enforced at the point of query planning, not at the point of data storage. This means that even if an agent is compromised or prompts are manipulated, the semantic layer’s row-level security prevents unauthorized data access. The agent never sees the raw data; it only sees the results filtered by the user’s role.

Next Steps for Implementation

If your organization is moving toward agentic AI, consider these steps:

  1. Audit Your Data Definitions: Identify critical metrics (like revenue or churn) and ensure they are defined consistently across all systems.
  2. Evaluate Semantic Layer Tools: Platforms like AtScale, Denodo, or Stardog offer different approaches (dimensional vs. graph-based). Choose one that fits your existing data stack.
  3. Implement Identity Propagation: Ensure your AI infrastructure can pass user identity tokens securely to the data layer. This is non-negotiable for compliance.
  4. Version Control Your Models: Treat your semantic models like code. Use Git for versioning and CI/CD pipelines for deployment.

The era of AI as a mere chatbot is ending. As agents gain the ability to act on data, the integrity of that data becomes the primary constraint on AI’s utility. By building a robust semantic layer, you ensure that your AI agents are not just smart, but also safe, consistent, and trustworthy.

Sources

Build a semantic layer for agentic AI on AWS with AtScale and Amazon Bedrock AgentCore | Amazon Web Services

Refer & earn

30% of their first month, then 10% every month after that

Refer a business to Faida Workforce and you earn 30% of the client’s first paid month, then 10% of every month for up to 24 months per client — rising to 15% from the accrual after you pass 10 active clients. Paid by PayPal, batched on the 1st.

10 Pro clients = $2,598.70 over 24 months — $3,748.13 at the 15% tier.

$8.99 Starter month 1, then $3.00/mo$17.99 Growth month 1, then $6.00/mo$29.99 Pro month 1, then $10.00/mo$14.99 Website Concierge month 1, then $5.00/mo$23.99 Human/AI Website Blogs month 1, then $8.00/mo
Join the partner programme

Figures are potential earnings worked from the published rates, assuming every referred client pays for the whole cap — not a promise, not an average. The $1 trial is never commissionable.

Written by
Editorial Workforce Desk

The Faida Workforce editorial team: practitioners who deploy AI employees in production, and write about what actually works. Every article is reviewed by a named human editor before publication.

All articles by Editorial Workforce Desk →

Written and edited by the Faida Workforce editorial team. Sources are linked in full; corrections and clarifications follow our editorial policy.

Editorial record. Reviewed and approved for publication by Workforce Editorial.

Spotted an error? Our corrections log records what changed and when, or tell us.

Scroll to Top