Agentic analytics on AWS without copying data: Stardog semantic layer and Amazon Bedrock AgentCore

TL;DR

  • What you get: a recipe to run agentic analytics on AWS without copying data, foundation model (Anthropic Claude Sonnet 4.6 on Amazon Bedrock), a semantic layer (Stardog knowledge graph), and an agent runtime (Amazon Bedrock AgentCore).
  • Why it matters: the semantic layer gives agents stable identifiers, shared business meaning, derived rules, and graph-level access control so answers are auditable and less prone to hallucination.
  • Try it: clone the Stardog C360 Knowledge Kit on GitHub to reproduce the demo, validate federation behavior, and measure latency/cost on your data.

Ask “who are our top spenders in Wisconsin?” and notice what breaks

Large language models are great at fluent answers but don’t know your canonical columns, which IDs link systems, or which fields are PII. Left unguarded, an agent can produce confident but wrong analytics. The practical fix is a semantic layer: an ontology-driven knowledge graph that maps live source rows to governed entities and exposes a single business meaning to agents.

Three cooperating layers for reliable agentic analytics

  • Model layer, the foundation model that plans multi-step workflows, writes queries, and composes answers. The reference implementation uses Anthropic Claude Sonnet 4.6 on Amazon Bedrock (Anthropic/AWS announce Sonnet 4.6 is generally available).
  • Meaning layer, an ontology-backed semantic layer (knowledge graph) that mints stable IRIs, defines classes and properties, encodes derived rules, and enforces access control (Stardog in the example).
  • Agent runtime, the operational host for agents and tools, handling inbound auth, routing, and credentials. The walkthrough recommends Amazon Bedrock AgentCore’s Runtime, Gateway, and Identity components.

High-level architecture and the key principle

Keep source data in place. Stardog virtual graphs map rows from Amazon Aurora, Amazon Redshift, and other sources to RDF triples at query time. Stardog rewrites SPARQL into source SQL over JDBC and joins results inside the graph. That trades ETL complexity for runtime joins and governance. Expect clear latency and cost implications you must measure.

Example data layout used in the demo kit

  • Amazon Aurora (operational), tables and 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), tables and 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 two systems share a business key, integer cid, which the semantic layer mints as a stable identifier. The example IRI template is:

urn:stardog:demos:c360:customer:{cid}

Minting stable IRIs simplifies federated joins, but production deployments usually need reconciliation and record-linkage when keys are messy.

What Stardog contributes

  • Ontology & mappings, the C360 example model has roughly ten classes and thirty properties. Stardog Designer authors the ontology and mappings. Designer persists models in Turtle and emits Stardog Mapping Syntax (a superset of R2RML).
  • Virtual graphs & federation, virtual graphs point to external sources (Aurora, Redshift, Athena/S3). At query time, Stardog rewrites SPARQL into SQL over JDBC for each source and composes results in the graph.
  • Reasoning & rules, OWL reasoning plus Stardog Rule Syntax (SRS) and SWRL can derive business concepts, for example classifying a customer as Big_Spender.
  • Access control, named graphs act as the unit of authorization so you can expose or hide PII at the graph level.

Stardog Cloud documents a 99.9 percent SLA, and the C360 Knowledge Kit (ontology, mappings, seed data, and SPARQL examples) is available on GitHub: github.com/stardog-union/knowledge-kits/examples/c360.

Small, concrete artifacts you can reuse

Mapping snippet (exact example used in the kit) that mints a stable customer IRI at query time:

BIND(TEMPLATE(“urn:stardog:demos:c360:customer:{cid}”) AS ?iri)

Illustrative federated SPARQL (shortened and annotated for clarity, the kit includes a full SELECT that aggregates spend):

SELECT ?cust ?name (SUM(?price * ?quantity) AS ?total) WHERE { … } GROUP BY ?cust ?name ORDER BY DESC(?total) LIMIT 10

Run the full SPARQL in the kit to validate federation behavior end-to-end. The demo seed data returns a top federated spender in the sample dataset, Carolyn Inworth, with $502, 529 total spend.

Two pragmatic agent→Stardog integration paths

  • Path A, Direct SPARQL tool: give the agent a SPARQL client (for example, the pystardog client) so it calls Stardog directly. This is simple, auditable, and gives you full control over tool design, observability, and retries.
  • Path B, Stardog MCP + Voicebox: Stardog’s MCP server (stardog-cloud-mcp) can expose Voicebox tools (voicebox_ask, voicebox_generate_query, voicebox_settings) that translate NL → SPARQL and return provenance. Voicebox API access may be gated; check Stardog Cloud for availability. MCP local mode is stable; remote modes have differing readiness levels.

Tradeoffs: Path A is straightforward and flexible. Path B speeds NL→SPARQL translation and supplies provenance traces, but it requires MCP/Voicebox access and adds another network hop and operational component.

Where to run the agent on AWS

The walkthrough authors recommend Amazon Bedrock AgentCore (Runtime, Gateway, Identity) as a production-ready runtime because it bundles inbound authentication, routing, and tool credential management. That reduces operational wiring for production agents. Anthropic Claude Sonnet 4.6 is shown as the foundation model in the example; Sonnet 4.6 is generally available on Amazon Bedrock.

Prompt caching: what to know (numbers from AWS documentation)

  • For Claude Sonnet 4.6, Amazon Bedrock’s prompt caching requires a minimum cache-prefix size of 1, 024 tokens, allows up to 4 cache checkpoints, and has a default TTL of 5 minutes (AWS documentation).
  • Prompt caching supports the InvokeModel and Converse APIs and is not supported for batch inference.
  • Billing nuance: cache reads are billed at a reduced rate while cache writes can be charged at a higher rate than uncached inputs, design checkpointing and cache lifecycles with that in mind.

In practice, prompt caching can reduce latency and input-token costs when agents repeatedly include a large static ontology or system prompt. Treat cached prompt content as sensitive if it contains policies or PII.

Governance and security patterns you can copy

Concrete pattern from the kit: split sensitive mappings into separate virtual graphs and use graph-level access control. For example, split Aurora mappings into:

  • aurora_c360_safe, customer profile without PII (:ssn:cardNumber omitted)
  • aurora_c360_pii, only the PII triples

Grant roles only the graphs they should access. For example, hr_user reads both graphs while marketing_user reads only the safe graph and the analytics graph. This keeps agents able to answer analytics questions while preventing PII leakage.

Operational tradeoffs you must plan for

  • Latency & cost: federation avoids copying data but issues multiple JDBC queries per federated SPARQL. Expect higher per-query latency and query costs versus pre-materialized views. Measure end-to-end time and per-source cost before committing to federation-only patterns.
  • Identifier and data quality: the demo assumes a clean shared key (cid). Real systems usually require record linkage, fuzzy matching, and reconciliation workflows. Model these into the ontology (sameAs links, provenance) and add reconciliation jobs where needed.
  • Reasoning at scale: OWL, SRS, and SWRL inference can derive useful metrics but can be expensive on large graphs. Use selective materialization, incremental inference, caching derived facts, or scope rules to subsets of data.
  • Auditability & provenance: log the NL prompt, the generated SPARQL, the rewritten SQL per source, source row IDs, and the named-graph permissions used. Auditors will want these artifacts to trace an agent answer back to its source.
  • Prompt cache sensitivity: cache content may include policy text or system prompts. Ensure encryption, key rotation, and access controls for any cached prompt material.
  • Feature readiness: Voicebox APIs, MCP remote mode, and other components may have differing GA or beta states. Verify feature availability and SLA commitments with Stardog.

Alternatives and when to consider them

This reference uses Stardog + Bedrock AgentCore, but the architecture pattern, foundation model, semantic layer, agent runtime, is portable. Other knowledge-graph platforms, self-hosted graph engines, or alternative agent runtimes can fill the same roles. Choose based on SLAs, networking and VPC needs, supported connectors (Snowflake, BigQuery, MongoDB, SAP HANA, etc.), and your team’s operational skills.

Practical checklist before you go to production

  • Version ontologies and mappings in Git; run CI tests that validate critical SPARQL queries and sample answers.
  • Measure baseline latencies: run a set of representative federated queries X times and capture end-to-end time and per-source query cost.
  • Decide materialization policy: which derived facts are computed on read versus materialized periodically?
  • Implement per-tool credentials in AgentCore Identity and require signed JWTs at the Gateway.
  • Log and retain: NL prompt, SPARQL, rewritten SQL, source row identifiers, named-graph ACL used, and the agent decision trace. Choose a retention window that meets compliance.
  • Treat prompt caches as sensitive; encrypt at rest and limit cache write frequency to control costs.

Try this in 90 minutes (practical, measurable steps)

  1. Clone the Stardog C360 Knowledge Kit: github.com/stardog-union/knowledge-kits/examples/c360 and follow the README to stand up the demo environment.
  2. Run the included federated SPARQL and capture end-to-end latency and the top results (demo seed returns Carolyn Inworth as the top federated spender in the kit dataset).
  3. Create a materialized view of the same join in Redshift (or a precomputed table) and compare latency and cost for the same query shape.
  4. Split Aurora mappings into safe vs PII graphs, grant a restricted role only the safe graph, and verify the restricted agent cannot return PII when asked.

Who contributed the walkthrough

Navin Sharma, Chief Product Officer, Stardog; JP Boreddy, Senior Solutions Architect, AWS; Sahil Thapar, Principal Solutions Architect, AWS; Raghu Prabhu, Principal Technical Product Manager, AWS. The C360 Knowledge Kit and artifacts are on the Stardog union GitHub repository linked above.

Key takeaways, questions you should ask

  • How do I stop my agent from inventing facts?

    Provide a semantic layer with stable IRIs, an ontology, and governed mappings so the model queries verified facts instead of guessing. A knowledge graph gives agents a single source of business meaning and rules to evaluate answers.

  • Can the agent run on AWS?

    Yes. The walkthrough uses Amazon Bedrock AgentCore (Runtime, Gateway, Identity) to host agents and Anthropic Claude Sonnet 4.6 as the foundation model. Sonnet 4.6 is generally available on Amazon Bedrock (per AWS).

  • Will prompt caching help?

    Often. For Claude Sonnet 4.6, Bedrock prompt caching requires a minimum 1, 024-token prefix, supports up to 4 checkpoints, and defaults to a 5‑minute TTL; cache reads are cheaper but cache writes may be more expensive, so design checkpoints and TTLs carefully (per AWS documentation).

  • Do I need to copy my data into the graph?

    No. The pattern federates Aurora and Redshift via virtual graphs so data stays in source systems; Stardog rewrites SPARQL to SQL over JDBC at query time. Federation avoids wholesale ETL but may require selective materialization for performance.

  • How do I protect PII from agents?

    Separate PII into its own virtual/named graph and use graph-level access control. Grant roles only the graphs they need. The kit demonstrates aurora_c360_safe and aurora_c360_pii as an example split.

Final note

Agentic analytics, agents that plan, query, and reason over live data, scales beyond simple prompt engineering only when it has a semantic backbone and operational safeguards. Use the semantic layer to give business meaning and auditability, run agents in a managed runtime that enforces auth and credentials, and measure latency and cost tradeoffs before you commit to federation alone. If you want a hands-on starting point, the Stardog C360 kit is a compact lab to prove the pattern in your environment.

0