AWS Context Ontology Accelerator: What It Does, What It Leaves to You, and How to Run It in Production
Key takeaways
- The AWS Context Ontology Accelerator is open-source software that drafts an ontology from your data, lets your experts review and approve it, and serves the result to AI agents over MCP. AWS released it under Apache 2.0 on July 31, 2026.
- It answers agents in three tiers, starting with governed metrics that need no model call, then structured queries over a virtual knowledge graph, then document retrieval and synthesis.
- It doesn't ship a model of your business. The definitions, the source of truth for each one, the access grants and the evaluation set all still come from your team.
- It's self-managed. You deploy and run it in your own AWS account, pin releases and carry the on-call, or engage AWS Professional Services.
- Production work is mostly identity, grants and testing. Agents query it as the signed-in user, so a messy entitlement model shows up in the first week.
- AWS says the accelerator's ontology capability will become a managed feature of AWS Context, and ontologies built with it now will carry over.
The Context Ontology Accelerator gives enterprise teams a faster way to turn scattered data into business context an AI agent can use. It speeds up the drafting of an ontology. It doesn't decide what your business means, who may see what, or how you'll prove that an agent's answer was right, and those decisions are where most of the production work sits.
We've been building data platforms on AWS since 2008, and this guide follows one question through the accelerator from start to finish. The company is made up but typical: a specialty commercial insurer writing commercial property and inland marine in 14 states. Its underwriting assistant, an agent on Amazon Bedrock AgentCore, kept getting one question wrong.
When an underwriter asked for the loss ratio on commercial property in the Southeast this quarter, the agent divided paid claims by written premium and said 41%. The chief actuary's number was 58%, because the company measures incurred losses against earned premium.
What Is the AWS Context Ontology Accelerator?
It's a self-managed, open-source accelerator that builds a machine-readable model of your business, covering your entities, the relationships between them and the rules that govern them, and serves that model to AI agents. AWS released it on July 31, 2026 under the Apache 2.0 license, describing it as a way to make agent decisions accurate, consistent, explainable and auditable.
The accelerator deploys into a single account and Region of your own. Its reference stack uses Amazon Neptune for the graph, Amazon OpenSearch Serverless for vectors and search, Amazon S3 for documents and ontology files, Amazon DynamoDB for operational state and Amazon Bedrock for enrichment. Agents reach it through an MCP server on Bedrock AgentCore Runtime, a REST API or a SPARQL endpoint. Your ontologies, mappings, SHACL shapes and governed metrics remain your content under the AWS Customer Agreement.
It works in three stages, and each one hands the insurer a decision the software can't make.
|
Stage |
What the accelerator does |
What the insurer had to decide |
|---|---|---|
|
Scan |
Connects to Glue Data Catalog databases, JDBC sources such as Redshift and PostgreSQL, Databricks and documents; discovers schemas, drafts descriptions and builds embeddings |
Which systems were authoritative for policies, claims and premium, and which tables the first release needed |
|
Model |
Induces OWL classes and R2RML mappings from approved tables, turns documents into classes and concepts, and holds each proposal for human review; stores governed metrics separately |
What a territory, an earned premium and a loss ratio meant, and who signed each definition |
|
Serve |
Answers questions through MCP, REST or SPARQL using three resolution tiers, with a Cedar admission check on every path and a SQL firewall on every SQL query |
Which users and groups could see which tables and columns, and how answers would be tested before release |
Which Problem Does It Solve for AI Agents?
It gives an agent the meaning behind the data, which retrieval and connectors alone don't. The insurer's assistant could already read every table it needed. What it lacked was the knowledge that "loss ratio" meant incurred losses over earned premium, that the Southeast was the company's own six-state underwriting region rather than the census definition, and that a claim belongs to a policy through a coverage line, not directly.
AWS is blunt about how slow this is by hand. Its announcement describes teams spending months reconciling definitions and encoding them into prompts and point integrations, and it says the accelerator cuts that ontology work from months to days. The months don't disappear entirely, in our experience, because the review and sign-off still take people's time. What changes is that experts edit a draft instead of writing a model from scratch.
Retrieval still has a place. An ontology in AI captures definitions, relationships and rules, while retrieval finds the passage in a document that explains them. The accelerator does both, and it keeps them in separate tiers so a governed number never comes back from a paragraph that happens to mention it.
|
Retrieval over documents |
The accelerator's ontology and metrics |
|
|---|---|---|
|
What it answered at the insurer |
Why the Southeast loss ratio rose, from catastrophe reports and underwriting memos |
What the loss ratio was, for which line, region and period |
|
Where it went wrong before |
Pulled a 2023 memo with a superseded territory map |
Not yet built, so the agent invented a formula |
|
What it needs from people |
Current, approved documents |
Signed definitions, mappings and grants |
How Does It Work: Scan, Model, Serve and the Three Answer Tiers
The insurer stood up the accelerator in a sandbox account in us-east-1 in August 2026 and followed the loss ratio question through all three stages. The walkthrough below uses the accelerator's documented workflow, and the company details are illustrative.
Scan: connect the sources and approve what enters the model
The data team registered the policy warehouse on Amazon Redshift and the claims database on Aurora PostgreSQL as JDBC sources, added the Glue Data Catalog over its S3 lake, and loaded underwriting guidelines and catastrophe reports as a document source. Credentials sat in AWS Secrets Manager, tagged to the namespace that was allowed to use them. Enrichment drafted descriptions and synonyms for about 380 tables. The team approved the 46 that underwriting questions touched and left the rest pending, because nothing enters the knowledge graph until a person approves it.
Model: induce, review and sign the ontology
Table-to-ontology induction proposed classes such as Policy, Coverage, Claim, Peril and Territory, with R2RML mappings that made each class queryable in SQL. Models on Amazon Bedrock described the classes, and the stewards edited the proposal before accepting it. They renamed a column called terr_cd to Territory, mapped the 14 states to the company's own regions, and rejected an inferred link between claims and policies that skipped the coverage line.
The loss ratio became a governed metric, written once as incurred losses divided by earned premium, with line of business, region and period declared as dimensions. The chief actuary signed it. A separate document induction turned the underwriting guidelines into concepts such as protection class and wildfire zone, which have no tables behind them and serve the document tier instead.
Serve: three tiers, tried in order
When an agent asks a question, the accelerator tries the most precise tier first and falls through to the next only on a miss. The insurer's three test questions each landed in a different tier.
|
Question |
Tier that answered and why |
What it ran |
|---|---|---|
|
"What's our loss ratio?" |
Tier 1, governed metric. The question named the metric and nothing else |
The pre-compiled SQL for the signed definition, with no model call |
|
"What's the loss ratio for commercial property in the Southeast this quarter?" |
Tier 1 when the agent passed line, region and period as dimensions; Tier 2 otherwise, because Tier 1 won't guess at qualifiers |
At Tier 2, SQL generated over the virtual knowledge graph from the governed formula, checked by the SQL firewall |
|
"Why did the Southeast loss ratio rise?" |
Tier 3, knowledge retrieval. The answer lives in documents, not tables |
Vector search and graph traversal, then synthesis on Bedrock, over the streaming endpoint |
The second row is the one that changed how the insurer configured its agent. Tier 1 deliberately declines a question that carries a filter, a time window or a different aggregate it can't apply, because answering from the metric would return the unfiltered total as if it were the narrower answer. When it steps aside, it hands Tier 2 the governed formula, so the generated SQL extends the actuary's definition rather than inventing a new one. The team taught the assistant to pass known filters as dimensions, which kept routine questions on the deterministic path.
Tier 3 needed a different integration. Synthesis over documents routinely takes 20 to 90 seconds, longer than the REST API's 29-second ceiling, so the assistant called it through the streaming endpoint on AgentCore Runtime instead.
What Does It Leave to You?
Everything that depends on knowing your business. The accelerator shortens the drafting. It doesn't settle ownership disputes, decide which system wins when two disagree, or make an agent safe to release, and AWS says as much. Its documentation states that customers are responsible for configuring authorization policies, defining PII classifications and maintaining data catalog accuracy, while AWS secures the underlying cloud.
|
What's left to you |
Why it mattered at the insurer |
What good looked like |
|---|---|---|
|
Business definitions |
Induction proposed a LossRatio class; only the chief actuary could say what it meant |
A signed definition and a named owner before the metric was published |
|
Source authority |
Premium appeared in the policy warehouse and in a finance extract with different cutoffs |
One ranked source per figure, with the reconciliation rule written down |
|
Access grants |
Underwriters in one state shouldn't see another state's large-loss files |
Per-group table allowlists and column denylists, tested with negative cases |
|
Action authority |
The assistant could recommend a rate change but must never file one |
Read-only access in the accelerator; any write tools scoped and approved separately |
|
Evaluation |
A plausible 41% looked as convincing as the correct 58% |
A set of questions with known answers, run before every release |
|
Compliance evidence |
State regulators ask how a rate-related figure was produced |
Lineage, query traces and approvals captured during the build |
It also doesn't ship a model of your industry. The accelerator can load public reference ontologies such as FIBO or Schema.org and ground new classes against them, and it accepts ontologies you upload, but the model of how your company works comes from your data and your people. The shape of that work varies by sector. A bank's first ontology usually starts with transactions and the rules around them, as in our context ontology for financial services work.
A health system's tends to start with patients, care teams and the reports they feed, which is the focus of context ontology for healthcare. A manufacturer's starts with parts, locations and shipments that carry different identifiers in every system, the problem behind our context ontology for manufacturing engagements.
What Does Running It in Production on AWS Take?
More than a demo does. A demo runs with a broad role, a handful of documents and friendly questions. The insurer's move from sandbox to production took most of its effort in three places: the deployment itself, the identity model and the tests.
Deployment and operations
The accelerator deploys with AWS CDK into one account and Region. The project's deployment guide says us-east-1 is the default and the only Region it has been validated in, and GovCloud and China Regions aren't supported. Bedrock AgentCore Runtime and Amazon DataZone are the narrowest constraints elsewhere, and the default model IDs are US cross-Region inference profiles, so a deployment outside the US won't build until its model settings are changed.
Because it's self-managed, upgrades are yours. The insurer pinned a tagged release, as the project recommends, rebuilt its sandbox from each new release before promoting it, and put the stack's CloudWatch dashboards and metrics in front of its platform team's on-call rotation.
Identity and authorization
Agents don't get credentials of their own. Users sign in through Amazon Cognito, any OIDC provider, or a SAML or OIDC provider federated through Cognito, and an agent calls the MCP server with that user's ID token. Grants are resolved from the email and group claims in that token. Authorization then runs at two points. A Cedar admission gate decides whether the caller may query the namespace at all, before any retrieval starts, and on the SQL paths a firewall allows only SELECT statements and enforces the caller's table allowlist and column denylist.
That model is strong, and it's unforgiving of a messy directory. The insurer found two groups that granted every claims table to anyone in underwriting, a holdover from a reporting project. Fixing them took longer than configuring the accelerator. It's the same principle that makes agentic RAG in production hold up, where permissions shape what's retrieved rather than what's shown afterward.
The production control set
|
Control area |
Minimum production standard |
How the insurer met it |
|---|---|---|
|
Identity |
User-delegated access through your identity provider; no shared service accounts |
Federated its corporate IdP through Cognito and retired a shared reporting login |
|
Authorization |
Cedar namespace policies and table and column grants per group, tested with negative cases |
Ran 30 deny tests per release, such as a Texas underwriter asking for Florida large losses |
|
Data protection |
PII classifications defined, sensitive columns denied by default, private connectivity to sources |
Denied claimant names and medical notes to every underwriting group |
|
Auditability |
Query traces, resolution tier, generated SQL and approvals retained under policy |
Kept traces with the agent's own logs for the regulator's retention period |
|
Evaluation |
Questions with known answers and release thresholds |
40 questions signed by underwriting and actuarial, all correct before promotion |
|
Change management |
Versioned ontologies, review of every proposal, a rollback plan |
Every re-induction went through a pending proposal and a named reviewer |
Two questions belong early in any regulated deployment. First, how will deletion, retention and access-request obligations reach the vector indexes, the graph and any caches? Second, what happens to past answers when a definition changes, and can you show which version of the ontology an answer used? The insurer answered both before go-live, because a state examiner could ask either one. Getting those controls in place is most of what separates AI agents in production from pilots.
How Does It Relate to AWS Context?
AWS Context is the managed service AWS announced in June 2026 to give agents business context across a company's data, and the accelerator is meant to feed it. AWS's July announcement says the accelerator's managed, user-defined ontology capability will become a fully managed feature native to AWS Context, and that customers who build ontologies with the accelerator will be able to use and manage them there.
As of mid-November 2026, AWS still lists AWS Context as coming soon, with re:Invent running from November 30 to December 4. That timing shaped the insurer's choice. Waiting would have meant another quarter of an assistant quoting 41%. Building on the accelerator meant the signed definitions, mappings and tests would carry over, stored in open W3C standards rather than in prompts.
Teams whose agents run on another platform face the same modeling work wherever the context lives, and the trade-offs between a Databricks ontology, Palantir, Microsoft Fabric IQ and AWS mostly come down to where the agents already run.
That's the work our context ontology services are built around. Forward-deployed engineers sit with the people who own your definitions, while agents handle the profiling, drafting and test generation. We deploy on the Context Ontology Accelerator in your own account today and move the model to AWS Context once it's available. Within a week of the first working session, you get a diagnosis, a draft first-release scope and a target production date.
