Before talking about AWS Context, let's first understand what context means in the AI world.
An AI agent can access data and process it, but does that mean it understands the data?
Consider an organization where information is spread across databases, documents, and different applications. An AI agent might be able to retrieve records from these sources. But without knowing how the information is connected or which business rules apply, it may struggle to give the right answer.
Think about attending a presentation. Before it starts, you might receive a brief explaining the background and the agenda. This helps you understand what will be discussed and why it matters.
Context plays a similar role for AI agents. It provides relevant information that helps them understand what they're working with and how different pieces of information relate to the task.
For example, retrieving a cloud resource record tells an agent that a resource exists. Knowing which application uses that resource, which environment it belongs to, and how its cost is attributed gives the agent a better basis for answering questions about it.
Context doesn't guarantee a correct answer, but relevant and reliable context can help an agent interpret information more effectively.
What is AWS Context?
AWS Context focuses on discovering relationships across existing enterprise data and representing them in a knowledge graph. This helps AI agents access relationships, business rules, and domain knowledge at runtime.
Rather than treating every record as an isolated piece of information, the idea is to make the connections between different pieces of data available to the agent.
AWS announced the service at AWS Summit New York City on June 17, 2026.
In the official AWS announcement, Mai-Lan Tomsen Bukovec describes context as the data lake for AI agents, highlighting its role in making enterprise knowledge available to AI systems.
Read the official AWS announcement.
2. Understanding the Components of AWS Context
To understand AWS Context, let's look at the main concepts behind making enterprise data useful to AI agents.
2.1 Relationship discovery
Organizations store information across databases, documents, and applications. Relationship discovery helps identify how entities and information from these different sources are connected.
Some relationships may be available directly from the source, while others may need to be inferred.
2.2 Knowledge graph
A knowledge graph represents entities as nodes and their relationships as connections between them.
For example, in a cloud environment, an application may depend on a compute instance, which is connected to storage and networking resources. Representing these relationships helps applications understand how resources are connected rather than viewing each resource in isolation.
2.3 Business rules and domain knowledge
Relationships alone don't always explain what the data means.
Business rules and domain knowledge provide additional information that helps an AI agent interpret those relationships in the right context.
2.4 Human review and curation
Automatically identified relationships may be incomplete or incorrect. Review and curation can help validate relationships, correct mistakes, and improve the quality of the information.
2.5 Context retrieval
An AI agent needs a way to retrieve relevant information when a question is asked. Context retrieval brings together the entities, relationships, and rules needed for a particular task.
2.6 Governance
Not every user or AI agent should have access to all enterprise information. Governance helps enforce access permissions and maintain appropriate control over how data is used.
2.7 Feedback and refinement
Context needs to remain useful as data and business requirements change. Evaluating retrieval results, correcting errors, and reviewing feedback can help improve context quality over time.
These concepts form a useful way to think about a context layer. The exact implementation and responsibilities of individual components depend on the system being built.
3. How Do These Components Work Together?
Let's take a simple example.
A user asks an AI agent: "Why is this cloud resource costing more than expected?"
The resource record alone might not explain the increase. The agent may also need information about the resource's workload, dependencies, environment, usage, and cost allocation.
A context layer helps connect these pieces of information.
Architecture overview
The following diagram illustrates a conceptual context-layer architecture. It is intended to explain the flow, not to represent AWS's official internal implementation.
Following the data flow
1. Collect information and discover relationships
The system works with existing data sources and identifies relevant entities and relationships. Depending on the source, relationships may be explicitly available or need to be inferred.
2. Build and enrich the knowledge graph
Entities and their relationships are represented in a graph. Business rules and domain knowledge add meaning to those relationships.
3. Retrieve relevant context
When a question arrives, the system retrieves the relevant entities, relationships, and rules. Access controls determine which information the requesting agent can use.
4. Generate an answer or recommendation
The AI agent uses the retrieved context to formulate its response. For a cloud cost question, this might mean examining resource usage alongside dependencies and cost information.
The quality of the answer still depends on the accuracy of the underlying data and the agent's reasoning. A knowledge graph helps provide context; it doesn't guarantee a correct answer.
The key idea: Instead of treating each record in isolation, a context layer makes relevant relationships available to applications when they need them.
4. Which Technologies Can We Use?
The technology depends on the type of data, relationships, and queries the application needs to support.
| Component | Possible technologies |
|---|---|
| Data integration | APIs, AWS SDKs, ETL pipelines |
| Knowledge graph | Neo4j, Apache Jena, Amazon Neptune |
| Business rules and ontology | OWL, RDF, SHACL |
| Context retrieval | REST APIs, SPARQL, Cypher |
| AI agent integration | MCP or custom tool APIs |
| Access control | IAM, application-level authorization, audit logs |
Do we always need a graph database?
No. PostgreSQL may be sufficient when relationships are simple and the data model is already relational. A dedicated graph solution becomes worth considering when complex, multi-hop relationship queries are central to the application.
5. Open-Source Alternatives
You don't need to start with a fully managed service to experiment with a context layer.
- Neo4j Community Edition: A graph database for storing entities and querying their relationships. Check its licensing and feature limitations before choosing it.
- Apache Jena: A Java framework for RDF data, SPARQL queries, ontologies, and inference.
- AWS Context Ontology Accelerator: An AWS-published, open-source project for building ontology-based context for AI agents. It uses AWS infrastructure, so open-source software does not mean the entire deployment is free.
Which should you choose?
Start with PostgreSQL if you want to validate the idea using an existing relational data model. Explore Neo4j or Apache Jena when graph traversal or formal ontology modelling becomes important.
If you want a working reference implementation on AWS, explore the Context Ontology Accelerator before building everything from scratch.
6. Where Can We Use This Architecture?
A context layer is useful when applications need to understand relationships across multiple data sources.
- AI assistants: Connect information from documents, databases, and internal applications.
- Cloud operations: Understand dependencies between cloud resources when investigating incidents.
- Enterprise search: Retrieve information based on relationships and business context, not just keywords.
- Security analysis: Connect identities, resources, and permissions to investigate potential risks.
The architecture should solve a real information problem. Adding a knowledge graph without a clear use case may introduce unnecessary complexity.
7. Applying These Ideas to Cloud Intelligence
This architecture also has potential applications in cloud intelligence platforms.
For example, understanding why a cloud resource is expensive may require more than looking at its monthly cost.
You may need to consider:
- Resource configuration and utilization.
- Relationships with other resources.
- Workload and environment.
- Cost attribution and ownership.
- Potential optimization opportunities.
At TattvaLens, we're exploring cloud intelligence around resource discovery, relationships, and optimization insights.
The broader engineering challenge is connecting these pieces of information so that recommendations have useful context behind them.
8. Trade-offs and Limitations
A context layer introduces its own engineering challenges.
- Data quality: Incorrect or outdated source data can lead to misleading conclusions.
- Relationship accuracy: Inferred relationships need validation and provenance.
- Operational complexity: A separate graph database adds infrastructure and maintenance overhead.
- Access control: Retrieved context must respect existing permissions.
- Cost attribution: Resource relationships alone don't determine how shared costs should be allocated.
- Evaluation: AI-generated answers and recommendations need testing against reliable evidence.
Start with the simplest architecture that meets your requirements. Introduce additional components only when their benefits justify the complexity.
Conclusion
AI agents need more than access to data. They also need relevant relationships and business context to interpret that data.
AWS Context highlights this problem at the enterprise level. The same architectural idea can be applied to other domains, including cloud operations and cost intelligence.
The interesting engineering question isn't simply how to store more data. It's how to make the right information and relationships available when an application needs them.
Top comments (0)