AI agents can generate answers, write code, and automate workflows. But when they work with enterprise data, one important challenge remains: understanding how information connects across different systems.
Imagine asking an AI agent:
"Why is this customer's order delayed, and are they eligible for a refund?"
The answer may require customer records, order details, shipment status, refund policies, and business rules from multiple systems.
Access to those sources is not enough. The agent needs to identify the correct relationships, retrieve relevant evidence, and follow the organization's access and approval rules.
This is the problem AWS Context is designed to address.
AWS introduced AWS Context in June 2026 as a forthcoming service designed to map relationships across enterprise data into a knowledge graph, helping agents retrieve governed context at runtime.
Check the latest AWS announcements for current service availability and supported capabilities before planning a deployment.
What Is AWS Context?
AWS Context is designed to connect enterprise data, business concepts, and organizational knowledge through a shared knowledge graph.
Its announced approach includes several capabilities:
- Relationship discovery: Identify relationships between data assets and business entities.
- Knowledge graphs: Represent connections between datasets, entities, and business concepts.
- Curated business knowledge: Allow data stewards to review relationships and attach trusted definitions and rules.
- Governed retrieval: Help agents retrieve context while respecting the access boundaries established for the requesting identity.
- Interoperability: AWS has described publishing key context metadata in Apache Iceberg format in Amazon S3 Tables for use with compatible tools.
The goal is to make enterprise knowledge reusable across multiple AI applications instead of embedding the same assumptions in every prompt.
Official announcement: https://aws.amazon.com/blogs/machine-learning/context-intelligence-for-your-data-and-ai-agents-at-scale/
Why Do AI Agents Need a Knowledge Graph?
Traditional retrieval-augmented generation (RAG) often retrieves documents or passages that match a question. This is useful, but individual documents do not always reveal all the relationships needed to answer a business question.
Consider this simplified knowledge graph:
Customer
|
| places
v
Order
|
| has
v
Shipment
|
| has status
v
Delivery Delay
Order
|
| evaluated under
v
Refund Policy
The graph connects the customer, order, shipment, and policy.
An agent can use these relationships to investigate a question rather than treating each record as an isolated piece of information.
For example, finding a refund policy is not enough. The agent must identify the relevant order, retrieve the current shipment status, and apply the correct policy.
A knowledge graph helps organize these relationships. The underlying data must still be reliable, and the agent must validate its findings before making decisions.
How AWS Context Fits into an AI Architecture
A simplified conceptual architecture looks like this:
User Request
|
v
AI Application
|
v
AI Agent
|
v
AWS Context
|
v
Governed Knowledge Graph
|
+--------+--------+
| | |
v v v
Customer Orders Policies
Data Data and Rules
|
v
Evidence-Based Response
|
v
Approval Before Action
This diagram illustrates the intended workflow, not a deployed AWS Context configuration.
The agent identifies the context required for a task, retrieves relevant relationships through configured interfaces, and uses the resulting evidence to prepare an answer.
Access controls are essential. An agent should not retrieve restricted records simply because they are connected to another accessible entity.
Mini-Project: Build a Context-Aware Customer Support Agent
Let's design a small customer-support workflow that connects customer information, order records, shipment status, and refund policies.
Project goal
The agent should:
- Identify the relevant customer and order.
- Retrieve the latest shipment status.
- Find the applicable refund policy.
- Explain the situation using evidence.
- Request human approval before executing a refund.
The following example uses fictional data. It demonstrates the intended workflow rather than a live AWS Context deployment or an executed integration test.
Step 1: Prepare sample data
Customer and order records:
| Customer ID | Order ID | Status |
|---|---|---|
| C101 | O501 | Shipped |
| C102 | O502 | Processing |
Shipment records:
| Shipment ID | Order ID | Shipment status |
|---|---|---|
| S801 | O501 | Delayed |
| S802 | O502 | Awaiting dispatch |
Sample business rule:
Refund eligibility depends on order status, product category, delivery conditions, and the applicable return window. A delayed shipment alone does not automatically guarantee a refund.
In production, these records should come from authoritative systems, and the refund rule should come from an approved policy source.
Step 2: Model the relationships
The context model might contain:
Customer C101
|
| owns
v
Order O501
|
| has shipment
v
Shipment S801
|
| current status
v
Delayed
Order O501
|
| evaluated against
v
Refund Policy
Where supported, record the source, freshness, and review status of important relationships. This helps distinguish verified facts from assumptions.
Step 3: Give the agent a task
Use this prompt in your prototype:
A customer wants an update on a delayed order. Identify the relevant order, retrieve its latest shipment status, locate the applicable refund policy, and explain the available options. Use only authorized data and approved rules. If required information is missing, state what is missing. Do not initiate a refund or modify the order.
The intended workflow is:
- Resolve the customer and order identifiers.
- Retrieve the authorized shipment record.
- Retrieve the applicable policy.
- Evaluate the available evidence.
- Produce an explanation with source references.
- Escalate if the evidence is incomplete or human review is required.
The exact retrieval APIs and implementation steps depend on the interfaces available in your environment. Check the current AWS documentation before implementing a specific SDK call or endpoint.
Step 4: Define the expected output
For fictional order O501, the agent could produce a response like this:
{
"order_id": "O501",
"shipment_status": "Delayed",
"policy_check": "Additional information required",
"explanation": "A shipment delay alone does not establish refund eligibility.",
"next_step": "Check the applicable return window and order conditions.",
"refund_execution": "NOT_EXECUTED",
"human_review_required": true
}
This is an illustrative response schema, not actual output from AWS Context.
The key behavior is that the agent does not invent a refund entitlement. It explains what is known, identifies missing information, and avoids executing an unapproved action.
Step 5: Add security and governance
For a production implementation, enforce controls outside the language model wherever possible.
- Least privilege: Give the agent only the access it needs.
- Identity-aware retrieval: Ensure user permissions constrain accessible data.
- Human approval: Require approval for refunds and other consequential actions.
- Source traceability: Preserve references to the data and policies behind an answer.
- Audit logging: Record relevant retrieval and execution activity.
- Freshness checks: Revalidate the order status before taking action.
- Safe failure handling: Escalate when records conflict or evidence is insufficient.
The goal is not simply to make an agent more knowledgeable. It is to make its decisions more explainable and controllable.
AWS Context vs. Traditional RAG
These approaches solve related but different problems.
| Capability | Traditional document RAG | AWS Context's announced approach |
|---|---|---|
| Main focus | Retrieve relevant document passages | Connect relationships and business context |
| Data representation | Documents, chunks, and metadata | Knowledge graph across connected data |
| Business definitions | Often supplied through documents or application logic | Can be curated in the context layer |
| Cross-source relationships | May require custom joins and retrieval logic | Relationship discovery is a core design goal |
| Governance | Depends on implementation | Designed around governed context retrieval |
They can complement each other. A knowledge graph might identify the correct refund policy and order, while a RAG system retrieves the detailed policy paragraphs.
A production architecture may benefit from both structured relationships and unstructured document retrieval.
Where Can This Make a Difference?
Customer support
Connect customer profiles, orders, shipments, support cases, and policies to provide more relevant answers.
Financial operations
Relate transactions, accounts, approval rules, and audit records to support investigations while preserving access controls.
Enterprise analytics
Connect metrics, data assets, ownership information, and definitions so agents can better understand what a metric means and where it originates.
Internal knowledge discovery
Help employees navigate relationships between teams, projects, systems, and documentation rather than searching for isolated documents.
The actual value depends on the quality of the data, the accuracy of the relationships, and the effectiveness of governance controls.
What Should Teams Evaluate Before Production?
Before adopting a context layer, ask:
- Data quality: Are source records accurate and consistently identified?
- Relationship quality: Can inferred relationships be reviewed before they affect important decisions?
- Authority: Which system is authoritative when sources disagree?
- Permissions: Does the user's identity constrain the context available to the agent?
- Freshness: How quickly are changes in data and policies reflected?
- Traceability: Can the team identify the sources and rules behind an answer?
- Evaluation: Are agent responses tested against known scenarios and conflicting evidence?
- Failure handling: Does the agent ask for clarification or escalate when context is incomplete?
A knowledge graph alone does not guarantee correct answers. Source quality, retrieval behavior, access controls, and testing remain essential.
Getting Started with AWS
AWS introduced AWS Context in June 2026 as a forthcoming service. Check the latest announcements and documentation for availability, supported regions, prerequisites, and integration details.
Useful resources:
- AWS Context announcement: https://aws.amazon.com/blogs/machine-learning/context-intelligence-for-your-data-and-ai-agents-at-scale/
- AWS Summit New York 2026: https://www.aboutamazon.com/news/aws/aws-summit-nyc-2026-ai-agents
- Context Ontology Accelerator: https://aws.github.io/context-ontology-accelerator/
- AWS Prescriptive Guidance on knowledge bases for agentic AI: https://docs.aws.amazon.com/prescriptive-guidance/latest/govern-architect-agentic-ai/core-services-knowledge-bases.html
If you want to experiment with knowledge graphs before a managed AWS Context deployment is available to you, explore the open-source Context Ontology Accelerator. It provides an alternative approach to modeling business entities and relationships, with human review and components such as Amazon Neptune, Amazon OpenSearch Serverless, and Amazon Bedrock.
Its setup is different from the managed service.
Conclusion
AI agents need more than access to data. They need to understand relationships, business definitions, and the rules that determine which information is relevant.
AWS Context is designed to address this challenge through a shared knowledge graph and governed context retrieval at runtime.
For teams building enterprise agents, the opportunity is to move from isolated answers toward decisions grounded in connected business information.
Start with a small workflow, validate the relationships and source data, enforce least-privilege access, and keep human approval in place for consequential actions.
The future of enterprise AI is not just about smarter models. It is about giving those models the right context, with the right controls, at the right time.
What enterprise workflow would benefit most from a shared knowledge graph in your organization?
Top comments (0)