Context Engineering for AI Agents, Beyond RAG

Context engineering for AI agents is the work of deciding what an agent knows at the moment it acts, and most teams still do it by stuffing text into a prompt and hoping the retrieval was good. AWS just open sourced a different answer: model your business meaning once as an ontology, then serve agents validated facts instead of ranked passages.

The repository (aws/context-ontology-accelerator) went public on July 28, 2026 and passed 290 stars a week later, on August 4. Seven days is not a track record, so the interesting part is not the star count. It is that an official AWS org published a full knowledge graph platform whose stated purpose is making agent decisions "more accurate, consistent, and explainable," and wired the output to agents over the Model Context Protocol.

Key Takeaways:

• Context engineering is shifting from prompt plumbing to data modeling. This project is the clearest expression of that so far from a major cloud vendor.
• The architecture is Scan, Model, Serve: connect sources and ingest documents, induce and manage ontologies, then serve context to agents via MCP.
• The difference from RAG is what comes back. Retrieval returns passages that look relevant. An ontology returns entities and relationships that were validated against rules.
• It is infrastructure, not a library. Deployment is AWS CDK with a control plane, namespaces, and role-based access control.
• Two dependencies carry copyleft licenses (PyMuPDF is AGPL-3.0, owlready2 is LGPL-3.0), which is a real review item for anyone redistributing.

---

What context engineering means once the window stops being the bottleneck

For most of the last two years, context engineering meant fitting things in. Summarize the history, rank the chunks, drop the middle, keep the token count under control. That framing made sense when windows were small.

The problem that replaced it is consistency. When two agents ask about the same customer and get two different answers because they retrieved two different documents, the fix is not a bigger window. The fix is having one definition of what a customer is, what fields are authoritative, and which relationships are allowed to exist. That is a data modeling problem, and it is old enough to have standards: OWL for the ontology, SPARQL for the queries.

AWS's project is a bet that agents will hit this wall in production and that the answer is the semantic layer the data world already built, connected to the agent layer through MCP.

What this proved: the vocabulary is moving from retrieval quality to semantic consistency. What it left unsolved: somebody still has to define the ontology, and that person is a data steward, not a prompt engineer.

---

What AWS actually shipped: scan, model, serve

The README describes a three-stage workflow, and reading it closely tells you how much of the pipeline is included.

Stage	What it does
Scan	Connects data sources, discovers schemas, enriches metadata, and ingests unstructured documents
Model	Induces and manages ontologies, defines metrics, and builds a unified semantic graph
Serve	Answers SPARQL federation queries through a virtual knowledge graph, traverses the graph, and serves context to AI agents via MCP

The packages line up with that: an ontology engine that runs the HermiT and ELK reasoners, a virtual knowledge graph built on Ontop, a metric service, a context manager that orchestrates queries, an MCP server, and a React admin app built on AWS's Cloudscape design system.

The word doing the most work in the name is "accelerator." This is not a component you add to an agent. It is a platform you stand up, with Smithy-generated API contracts, AWS CDK stacks per service, and a control plane in front of it.

---

Ontology versus RAG: what actually changes about the answer

The honest comparison is not that one wins. They return different kinds of things.

	Vector retrieval	Ontology-backed context
What comes back	Passages ranked by similarity	Entities and relationships
Why it is right	It looked closest in embedding space	It satisfied the rules in the model
Failure mode	Confidently retrieves the wrong doc	Returns nothing, or fails validation loudly
Explaining an answer	Cite the chunk you retrieved	Trace the path through the graph
Setup cost	Embed a corpus	Model a domain

The failure modes are the part worth sitting with. A retrieval system's worst behavior is quiet: it hands the model a plausible passage from the wrong quarter, and the agent writes a confident, wrong answer. A graph query's worst behavior is loud: nothing matches, or the reasoner rejects it. Loud failures are cheaper to operate, which is the entire argument for putting a semantic layer under an agent that touches money or contracts.

Where the ontology approach gets expensive is that "model a domain" is not a weekend. The project includes ontology induction to soften that, meaning it tries to derive structure from schemas and metadata rather than making you author everything by hand. How well that works on a messy real warehouse is exactly the thing seven days of public history cannot tell you.

What this proved: for decisions that must be defensible, structure beats similarity. What it left unsolved: induction quality is unproven in public, and it is the difference between a two-week and a two-quarter adoption.

---

Serving context to agents over MCP is the load-bearing choice

The design decision with the longest tail is that the serve layer speaks MCP.

That means the graph is not wired into one framework. Any MCP-capable agent can query it as a tool, which is the same reason MCP spread through the agent ecosystem in the first place. Your agent does not need to know SPARQL or that a virtual knowledge graph exists. It calls a tool, gets back structured context, and acts.

It also means the boundary is clean enough to swap. If the ontology layer disappoints, the agent side does not get rewritten, because it was talking to a protocol rather than to a vendor's SDK. That is the same separation that makes the agent harness layer replaceable: the runtime and the knowledge it draws on are different purchases. Teams evaluating this should treat that as the main risk reducer: adopting it is closer to adding a tool server than to adopting a framework.

---

Governance is the quiet feature nobody puts in the headline

The access model is more developed than a seven-day-old repository usually bothers with. There are namespace-scoped roles (owner, maintainer, data-steward, data-analyst) plus platform-level roles that apply across all namespaces, documented in the control plane package.

Read that as a statement about who this is for. A hobby project serving context to an agent does not need a data-steward role. An enterprise that wants agents reading from governed data, with an audit trail for which namespace an answer came from, needs exactly this, and it is usually the thing that blocks agent rollouts long after the demo worked.

If your agent program has stalled at "legal will not let it near the warehouse," the interesting part of this repository is the control plane, not the reasoner.

---

What adoption actually costs

The prerequisites tell the real story: Python 3.12, Node 22 or newer, Docker, pnpm, uv, and Java 17 with Gradle for the Smithy codegen. That is a build, not an install.

Two more items belong on a review checklist before anyone commits:

1. Copyleft dependencies. The README's own external dependency table lists PyMuPDF under AGPL-3.0 and owlready2 under LGPL-3.0. For internal deployment that is usually fine. For anything you redistribute or offer as a service, AGPL is a conversation with legal, and AWS's own text says to consult your open source approval policy before proceeding.
2. Maturity. It is an accelerator published by AWS, not a GA service with a support commitment. Treat the roadmap as unannounced.

Set against that, the alternative is not free either. Teams that skip the semantic layer end up hand-writing the same joins into a dozen agent prompts and rediscovering the inconsistency later, usually in front of a customer.

---

Where an ontology is overkill

Most agent work does not need this, and pretending otherwise is how good architecture gets wasted.

If an agent reads a handful of documents, drafts something, and a human approves it before anything happens, retrieval is fine and a graph is ceremony. The same is true for research tasks where the source is the open web rather than governed internal data, and for anything where being approximately right is acceptable because a person reads the output anyway.

The line is roughly this: when the agent's answer is the final answer, and being wrong is expensive or has to be explained afterward, the structure earns its cost. Below that line, better retrieval and a clear tool boundary get you most of the value at a fraction of the setup.

For the more common case, the practical version of context engineering is narrower: give the agent the right tools, a persistent place to keep what it learned between runs, and a clear scope. That is closer to what our agent architecture guide describes, and why agent memory and chat history are worth separating in your own design before you reach for a knowledge graph. A hosted agent with deep research built in covers the open-web half of that without any of the modeling work, which is the right starting point unless your context problem is specifically about governed internal data.

---

FAQ

What is an ontology in the context of AI agents?

A formal model of the entities in a domain, their attributes, and the relationships and rules that constrain them. In practice it is the difference between a document that mentions a customer and a machine-checkable statement that a customer has exactly one billing account and at least one contract. Agents query the model rather than reading around it.

How is this different from RAG?

RAG returns text that scored highly on similarity. An ontology-backed layer returns entities and relationships that satisfied the model's rules, so the answer can be traced and validated. They also fail differently: retrieval fails quietly with a plausible wrong passage, a graph query fails loudly by returning nothing.

Is the AWS context ontology accelerator open source?

Yes, Apache-2.0 on GitHub, published under the official aws organization. Some of its dependencies carry different licenses, including AGPL-3.0 for PyMuPDF, which matters if you redistribute rather than deploy internally.

Do I need AWS to run it?

The deployment path is AWS CDK, so it is built for AWS. The individual pieces (Ontop, OWL reasoners, an MCP server) are not AWS specific, but treating this as cloud portable would mean rebuilding the infrastructure layer.

Does my agent need to understand SPARQL?

No. The serve layer exposes context through MCP tools, so the agent makes a tool call and receives structured context. SPARQL stays inside the platform.

---

Context engineering for AI agents is a data modeling problem in disguise

The reason this repository is worth a look at 290 stars, when plenty of louder projects are not, is what it signals rather than what it ships. A major cloud vendor is arguing in public that the ceiling on agent reliability is semantic, not architectural, and that the fix is the boring discipline of modeling your domain properly.

That argument will outlive this particular codebase. If you are building agents that make decisions somebody has to defend later, the question to carry away is not whether to deploy this specific accelerator. It is whether anyone on your team can say what your core entities are without opening a table.

Repository figures verified on GitHub on August 4, 2026. Architecture and dependency details from the project README as of the same date.