AWS上でStardogとAmazon Bedrock AgentCoreを用いたエージェントAI向けセマンティックレイヤーの構築方法

In this post we show how to build a semantic layer on AWS using Stardog’s Semantic AI Application over Amazon Aurora and Amazon Redshift, and how to run a Strands Agents agent on Amazon Bedrock AgentCore that queries the layer to answer customer 360 questions across both sources without extract, transform, and load (ETL). The same Stardog deployment works behind AWS computes (Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Container Service (Amazon ECS), and AWS Lambda). We use AgentCore here because it bundles inbound auth, hosting, and tool credentials into one managed service.

Enterprise analytics has been chasing the same goal for two decades: shrink the time between a business question and a trustworthy answer. Scheduled reports gave way to dashboards, then dashboards gave way to self-service business intelligence (BI). Even self-service depended on a data engineer having already built the right model for the right question, and the human analyst remained the bottleneck for everything outside the prepared dataset. Generative AI agents are the next step. Instead of visualizing data, they reason over it. They plan, write queries, evaluate results, refine, and iterate against the company’s live data on demand. *Agentic analytics* is the term for this shift: an autonomous agent at every business user’s elbow, doing the analyst’s work without waiting in the request queue.

The hard part is no longer the foundation model (FM). Foundation models available on Amazon Bedrock can already plan multi-step workflows, reason about schemas, and produce SQL well enough to act as a junior analyst would. The hard part sits underneath: the data the model reasons over. Enterprise data is scattered across systems that define the same things differently. The “customer” in your customer relationship management (CRM) system is not the same record as the “customer” in your billing system. “Revenue” calculated by the North American team isn’t the same number the European team would produce. An AI agent given direct access to this fragmented data will write technically valid queries that return wrong, conflicting, or unexplainable answers. Confidence erodes the first time two agents return two different numbers for the same question.

On AWS, that data sits across a familiar mix. Operational records live in Amazon Aurora and other Amazon Relational Database Service (Amazon RDS) engines. Analytics history lives in Amazon Redshift. Unstructured data lives in Amazon Simple Storage Service (Amazon S3), queried through Amazon Athena, and increasingly in open table formats such as Apache Iceberg, on Amazon S3 Tables, a capability of Amazon S3, which Athena, Amazon EMR, and Amazon Redshift can all read. Each layer is purpose-built for what it stores and most enterprises will keep that shape. The challenge is helping an AI agent reason across all of them at once with the same fluency a senior human analyst would bring to the same question.

Foundation models bring the language and the AWS data application brings the facts. The familiar way to connect them today is Retrieval Augmented Generation (RAG): index policy documents, manuals, and support tickets into Amazon Bedrock Knowledge Bases and pull matching passages into the model’s context at query time. RAG works well when the answer lives in text the search can find. It works less well for analytical questions where the answer depends on joining live records across systems, applying a business rule consistently, and honoring row- or column-level access policies.

What sits between language and facts, and is usually missing for those analytical questions, is *business context and business metrics*. Take a typical retail example: a shared definition of what a *customer* is, how an *order* links to one, what counts as a *big spender* or a *high-risk account*, which system owns which fact, and how the numbers the business reports are computed. The same gap shows up in other domains (claims and policies in insurance, patients and encounters in healthcare, parts and shipments in supply chain) under different names. A semantic layer captures that context once and lets every agent and tool reuse it. With it, an AI agent can compose answers from many sources and stand behind the numbers it returns. A semantic layer doesn’t replace RAG. It complements it. Most production systems need both, reachable through the same agent.

A semantic layer is an ontology-driven view of your enterprise data. The ontology captures the concepts, relationships, attributes and rules that matter to your business. Mappings declare how those concepts are mapped from rows in each live source. The agent queries the layer. The layer translates each query into SQL against the underlying systems at runtime. Data stays where it is. Meaning is captured once and reused.

When that semantic layer is implemented as Stardog does it (an ontology, stable identifiers for every entity, and rules that derive new facts, and constraints that validate the data against the ontology) the result is a *knowledge graph*. The data is connected as a graph of business entities rather than rows in tables, every entity has a stable URL-style unique identifier called an IRI, and queries traverse those connections in a W3C-defined, standards-based query language called SPARQL. Two more terms come up repeatedly in the rest of the post:

• A named graph is a labeled subset of the graph, identified by an IRI of its own. Stardog uses named graphs as the unit of access control. The same query produces different results for different roles depending on which named graphs each role is allowed to read.

• A virtual graph is a named graph whose contents are not stored in Stardog at all. They live in an external system (Aurora, Amazon Redshift, Athena) and Stardog fetches the rows on demand using the mappings. Federation in this post is implemented as a set of virtual graphs, one per source.

The Stardog glossary defines each of these terms, and the Stardog Getting Started series puts them in context.

By the end of this post you will know:

• How a semantic layer fits alongside RAG, and when to pick each.

• How to federate Stardog across Amazon Aurora and Amazon Redshift, with notes on extending to Amazon Athena and other AWS data sources.

• Why we recommend AgentCore Runtime, Gateway, and Identity for running the agent in production.

• Two integration paths from the agent to Stardog: a direct SPARQL tool, and the Stardog Cloud Model Context Protocol (MCP) server as a Gateway tool target.

• Tradeoffs on governance, deployment, and what is generally available (GA) versus beta today.

Three layers an agent needs

An AI agent that gives reliable, business-context-aware answers depends on three things working together. Each one solves a problem the others can’t.

1. Model layer. A foundation model that can plan and write. Amazon Bedrock provides a single API to multiple model families. We use Anthropic Claude Sonnet 4.6. The model knows language, it doesn’t know your business.

1. Meaning layer. A semantic layer that gives the model trustworthy, governed access to the data behind your business questions. The ontology declares the concepts and the rules that derive new facts from them, and the federation pulls live rows from each source at query time. The layer does the work: it figures out which data is relevant, rewrites the SPARQL query into SQL for each source, and joins the rows on shared identifiers. The model has a narrower job. It reads the user’s question, calls the layer when it needs data, and writes the answer in plain English. The actual reasoning over data, like applying the Big_Spender rule across the federated sources, stays inside Stardog rather than inside the prompt. We use Stardog’s federated knowledge graph over Aurora and Amazon Redshift for this.

1. Agent runtime layer. The compute that hosts the agent, terminates inbound requests, manages tool credentials, and provides the operational surface for security and governance. On AWS you have a spectrum of choices: managed runtimes like Amazon Bedrock AgentCore at one end, and self-managed options like Amazon ECS, Amazon EKS, or AWS Lambda at the other. The right choice depends on how much of the agent operations you want to own. We use Amazon Bedrock AgentCore in this post because it is the most prescriptive of the options for production agents on AWS.

Of the three, the meaning layer is the gap this post is about, and the rest of the walkthrough builds it. The agent runtime layer is the one most teams underestimate: how does the agent get called, how does it authenticate, where does its credential to the semantic layer live, and how does it scale. AgentCore packages answers to those questions into one managed service, which is why we use it here.

Example use case: A customer 360 agent across Aurora and Amazon Redshift

We chose customer 360 (C360) for the rest of this walkthrough because it surfaces every gap an AI agent runs into the moment it tries to do real analytical work, and it lets us show how the semantic layer closes each one in a few hundred lines of mappings and rules. In a typical retail setup, customer profile, address, credit card, and rewards information sit in an operational database. Orders, products, categories, and vendors live in a data warehouse for analytics. Each side is well-tuned for what it does. Neither side, on its own, can answer a question about the customer as a whole. An agent that tries to answer “who are our most valuable customers, and what are they buying?” has to reconcile two databases, two schemas, two definitions of “customer”, and a derived idea (“most valuable”) that lives in nobody’s column. C360 makes those gaps concrete.

The C360 agent runs for the analytics team. It accepts a question in plain English from a sales lead, a marketer, or a fraud analyst. It writes the queries, runs them across the company’s data, and replies with a short narrative answer plus the supporting numbers. The user does not see SQL or SPARQL, and the agent does not see the data it is not allowed to see.

A user asks the C360 agent, in plain English: *“Who are our top spenders in Wisconsin?”* Customer profile and address live in Aurora. Order totals live in Amazon Redshift. The agent has to join them on a stable customer identifier, and that join is one of three things a semantic layer adds:

1. Joins across systems through shared meaning. The semantic layer maps customer records from both Aurora and Amazon Redshift to a common customer identity using shared business keys. This lets the join be expressed through the semantic model rather than a physical integration pipeline. Without it, that join often requires a maintained pipeline that materializes a third copy of the data and must be kept in sync each time either source changes.

1. Derived facts as rules, not queries. A definition like “big spender” can live in the ontology as a rule rather than being re-expressed in every query, and every query that mentions it gets the same answer. Without it, that definition gets duplicated across dashboards, notebooks, and reports. When the threshold changes, the copies drift apart and the same question starts returning different answers.

1. Graph-level access control. Named graph security controls access at the graph level, so different roles see different subsets of the enterprise knowledge graph. For more fine-grained protection, you can designate sensitive properties such as :ssn and :cardNumber as protected properties. Users with permission see the actual values, while others see masked values by default. With this approach, different roles can run the same query while the knowledge graph enforces consistent security policies across every application that accesses it.

We took Stardog’s C360 Knowledge Kit, which originally loads local CSVs, and adapted it to federate across Aurora PostgreSQL (customer side) and Amazon Redshift (purchase side). The kit ships an ontology, sample data, and ready-made queries. You can use it as the starting point for your own work.

The data model the agent does not see

Underneath the agent, the C360 data is split across two AWS databases. Aurora holds the operational, customer-facing tables. Amazon Redshift holds the analytics fact table and product dimensions.

Aurora PostgreSQL (operational)

Table

Key columns

customer

cid, first_name, last_name, email, ssn, phone, location

address

id, city, state, zip, street_name

credit_card

id, cid, card_num, card_type

rewards_account

id, cid, account_id, create_date

Amazon Redshift (analytics)

Table

Key columns

purchase

id, cid, pid, date, quantity, price, card

product

id, name, brand, price, dept

category

id, dept_name, parent

vendor

id, vendor_name, industry

The shared identifier across the two databases is the integer cid. It appears as a primary key in the customer table on Aurora and as a non-foreign-key column in the purchase table on Amazon Redshift. There’s no SQL constraint linking them. There can’t be: they live in different engines. Answers that join customers to their orders must reconcile that integer at query time, every time, without ETL.

This is what the semantic layer absorbs. The ontology declares one concept, :Customer, and one stable identity for it: an IRI of the form urn:stardog:demos:c360:customer:{cid}. Both the Aurora customer mapping and the Amazon Redshift purchase mapping mint that same IRI from their respective cid values. The agent sees one customer entity with a profile, addresses, cards, rewards accounts, and orders. The warehouses see their own rows, unchanged. The mappings mint the same customer IRI from the cid in both databases. Stardog uses that shared identity to join the federated results without requiring the underlying databases to know about one another.

Reference architecture

*Figure 1. Key point: data stays in Aurora and Amazon Redshift. Only queries flow through the semantic layer.*

This is the recommended production architecture. The proof of concept (POC) for this post used Path A with the agent running as a standalone script.

The diagram shows two flows.

Inbound. A client (an application, another agent, or Stardog Studio) calls the agent through AgentCore Gateway. Gateway validates the inbound JSON Web Token (JWT) and routes the call to AgentCore Runtime, which hosts the Strands agent. The agent invokes Claude Sonnet 4.6 on Amazon Bedrock for planning and answer composition.

Outbound to the semantic layer. Two paths are shown.

• Path A (today, orange dashed): The Strands agent calls a query_kg SPARQL tool that talks to Stardog directly. Use this when you don’t yet have Voicebox API access (described later in this post).

• Path B (Stardog Cloud MCP, when API access is available, blue): AgentCore Gateway has the Stardog Cloud MCP server registered as an MCP target. Gateway pulls the Stardog token from AgentCore Identity and forwards the call. The agent doesn’t touch the credential.

Stardog itself federates to the warehouses at query time over Java Database Connectivity (JDBC). SPARQL is rewritten to SQL per source. Results are joined inside Stardog on shared IRIs. There is no ETL job and no third copy of the data.

Build the semantic layer

Three pieces make the federation work. The ontology declares the concepts (:Customer, :Order, :Product) and the relationships between them. The mappings declare how rows in each datastore become instances of those concepts. Reasoning rules derive new facts from the data already in scope. Stardog Designer is the authoring surface for all three.

The ontology

*Figure 2. The C360 model in Stardog Designer. Concepts like* Customer*,* Order*,* Product*, and* Address *appear as colored nodes connected by labeled relationships (*purchased*,* card holder*,* has address*,* in category*). The lighter-shaded nodes around the edges (*Big Spender*,* Large Order*,* 2022 Orderer*, the* Sports Category *shopper) are derived classes inferred by reasoning rules in the model rather than columns in any source.*

The C360 ontology is authored in Stardog Designer, a no-code visual modeling and mapping tool. The modeler creates concepts (:Customer, :Order, :Product), connects them with relationships (:purchasedBy links an :Order</co