Build a semantic layer for agentic AI on AWS with Stardog and Amazon Bedrock AgentCore

AWS and Stardog published a joint walkthrough showing how to deploy a semantic layer that lets AI agents query multiple data sources—Aurora and Redshift in this case—without ETL. The approach uses Stardog's Semantic AI Application to create a unified knowledge graph, then exposes it to an agent running on Amazon Bedrock AgentCore. For SMBs with data scattered across RDS, Redshift, or third-party SaaS, this pattern offers a way to answer "customer 360" questions without building brittle pipelines.

What AWS announced

AWS published this on their Machine Learning blog as a joint post with Stardog. The architecture deploys Stardog on AWS compute (EKS, ECS, or Lambda) to sit between your data stores (Aurora, Redshift) and an AI agent. Stardog builds a semantic layer—a knowledge graph that maps entities and relationships across both databases—so the agent can query "show me all orders for customer X" without knowing which table lives in which system.

The agent itself runs on Amazon Bedrock AgentCore, a managed service that bundles inbound authentication, hosting, and tool credentials. You define the Stardog semantic layer as a tool, and the agent calls it via natural language. No custom API gateway, no Lambda authoriser, no credential juggling in your code.

The post walks through: - Deploying Stardog on EKS (Kubernetes) with Helm. - Connecting Stardog to Aurora (transactional data) and Redshift (analytics data). - Defining a knowledge graph schema in SHACL (Shapes Constraint Language). - Creating a Strands Agents agent (Stardog's agentic framework) that queries the graph. - Exposing the agent as a tool in Bedrock AgentCore. - Querying the agent from a front-end (Streamlit demo included).

The key claim: the agent answers questions like "What are the top 5 customers by revenue in Q4 2024?" by reasoning over the semantic layer, which federates queries to Aurora and Redshift behind the scenes. No ETL job, no data warehouse sync.

Why this matters for SMBs

Most SMBs we work with have data in 2-4 places: Postgres on RDS, a Redshift cluster for analytics, maybe Stripe or HubSpot via API. When you want to build an AI assistant that answers "show me high-value customers who haven't ordered in 60 days", you face two bad options:

ETL everything into one warehouse. Expensive, slow, breaks when schemas change.
Write custom code to join data in the agent. Brittle, hard to maintain, doesn't scale beyond 2-3 sources.

A semantic layer sidesteps both. You define entities (Customer, Order, Product) and relationships (Customer placed Order) once, in a graph schema. The semantic layer translates natural language queries into SQL or API calls to the underlying sources, then stitches results together. The agent sees one unified model.

For a 10-person SMB running €6k/month on AWS, this pattern makes sense if: - You have 2+ data sources you need to query together (RDS + Redshift, or RDS + third-party API). - You're building an internal AI assistant (support, ops, finance) that needs to answer cross-system questions. - You don't want to hire a data engineer to maintain ETL pipelines.

The trade-off: Stardog is a commercial product (they offer a free tier for dev, but production requires a licence). If your data is simple and fits in one Postgres schema, you don't need this. But if you're already paying for Redshift and RDS, and you're considering Fivetran or dbt Cloud to sync them, a semantic layer might cost less and give you more flexibility.

How we'd apply it at Enekui

We'd deploy Stardog on ECS Fargate (not EKS) to keep ops simple. EKS adds Kubernetes overhead; for a single Stardog instance serving 5-10 queries per minute, Fargate is cheaper and easier to patch. We'd connect it to Aurora Postgres (transactional) and a small Redshift Serverless endpoint (analytics). Schema definition in SHACL takes 1-2 days for a typical SMB data model (Customer, Order, Invoice, Product).

For the agent, we'd use Bedrock AgentCore with Claude 3.5 Sonnet as the LLM. We'd define the Stardog semantic layer as a tool using OpenAPI spec (Stardog exposes a REST API). The agent would handle queries like "Which customers have unpaid invoices over €5k?" by calling the semantic layer, which federates to Aurora (invoices) and Redshift (customer lifetime value).

We'd skip the Strands Agents framework (Stardog's proprietary agentic layer) and use Bedrock's native agent orchestration. Simpler, one less vendor, and Bedrock's tool-calling is mature enough for this use case.

Infrastructure: Terraform module for ECS Fargate + Aurora + Redshift Serverless + Bedrock AgentCore. Stardog config in a Docker image, schema in version control. Total setup: 2 weeks for a 3-source semantic layer (RDS, Redshift, one SaaS API).

Cost for a small SMB: Stardog licence (contact them for pricing, likely low hundreds per month for <5 users), ECS Fargate ~€50/month, Redshift Serverless ~€100/month for light usage, Bedrock API calls ~€20/month for 1,000 queries. Total ~€200-400/month depending on Stardog tier. Compare that to Fivetran (€500+/month) plus dbt Cloud (€100+/month) for the ETL alternative.

Code snippet: querying the semantic layer from Bedrock

Here's how you'd call the Stardog semantic layer from a Bedrock agent tool (Python SDK):

import boto3

bedrock_agent = boto3.client('bedrock-agent-runtime')

response = bedrock_agent.invoke_agent(
    agentId='your-agent-id',
    agentAliasId='your-alias-id',
    sessionId='session-123',
    inputText='Show me customers with unpaid invoices over €5k'
)

for event in response['completion']:
    if 'chunk' in event:
        print(event['chunk']['bytes'].decode('utf-8'))

The agent calls the Stardog tool behind the scenes. Stardog translates the question into SPARQL (graph query language), federates to Aurora and Redshift, and returns JSON. The agent formats it into natural language.

Caveats

Stardog is not open source. You're locked into their licence model. If you want a free alternative, look at Apache Jena or Oxigraph, but you'll write more glue code.
Performance depends on your data sources. If Aurora or Redshift is slow, the semantic layer won't fix it. You still need indexes and query optimisation.
Schema maintenance is real work. When you add a new table or change a relationship, you update the SHACL schema. For a 5-table model, this is 30 minutes per change. For a 50-table model, budget a part-time data steward.
AgentCore is new (GA in late 2024). We've tested it on 3 client projects; it's stable, but documentation is thinner than Lambda or ECS. Expect some trial and error.

When not to use this

Your data fits in one Postgres database. Just query Postgres directly from the agent. No semantic layer needed.
You need sub-second latency. Semantic layers add 200-500ms per query (network hops + graph reasoning). For real-time dashboards, use a materialised view in Redshift.
You have <2 data sources. The complexity isn't worth it. Use a simple Lambda function to join data.

What this means for your SMB

If you're building an AI assistant that needs to answer questions across RDS, Redshift, and maybe a SaaS API (Stripe, HubSpot), a semantic layer is the cleanest architecture we've seen. It avoids ETL pipelines, keeps your data in place, and gives the agent a unified view.

The AWS + Stardog post is a good reference architecture. We'd simplify it (ECS instead of EKS, skip Strands Agents), but the core pattern—semantic layer as a Bedrock tool—is solid.

For a 10-person SMB, budget 2 weeks to deploy (Stardog + schema + agent) and €300-500/month to run. If you're already spending that on Fivetran or hiring a contractor to maintain ETL scripts, this is a better investment.

Want help shipping this? We offer a 2-week cloud diagnosis (€2,900) where we map your data sources, design a semantic layer schema, and give you a Terraform module + agent prototype. Book a call.