AWS Context: AWS's Automated Knowledge Graph for AI Agents

At the 2026 AWS Summit in New York, AWS introduced AWS Context, a new service that maps relationships across an organization's existing data into a knowledge graph and provides agentic search, enabling AI agents to access governed data relationships, business rules, and domain knowledge at runtime. The problem it targets is one most teams running agents on enterprise data have already hit: agents fail because they lack the context to reason over enterprise data.

While AWS Context was announced, it’s listed as coming soon and isn't available as of the publication of this article. This blog is for technical and business-technical leaders deciding how much weight to put on the launch. We’ll dive into what AWS Context is and isn't, what makes us think it has big potential, which claims to take seriously, what remains unproven until we can get our hands on it, and what you can responsibly do now.

What is AWS Context

AWS Context is a new service that infers how an organization's data relates, which tables connect to which, what columns mean, how sources fit together, and represents those relationships as a graph agents can traverse. This enables agents to answer a question by combining semantic matching with graph-level reasoning across structured and unstructured sources rather than keyword lookup against a single store.

The part that separates AWS Context from an automated catalog is the human control plane. Data stewards and curators work the graph through a console, reviewing the relationships the service infers, promoting those they trust to production, and attaching domain knowledge such as business definitions and usage rules. AWS Glue Data Catalog, Amazon SageMaker Unified Studio, and AWS Lake Formation connect into the graph, so existing governance and permissions carry through.

What is Behind AWS Context?

The core technology of AWS Context is already running in production. AWS built Context on the same knowledge graph that powers Amazon Quick, the agentic assistant AWS made generally available in late 2025. In Amazon Quick, that same graph catalogs datasets, dashboards, and metadata.

What AWS Context does is change the scope of that graph from personal to organizational. Amazon Quick's graph learns one person's data and habits, while AWS Context maintains a shared, governed graph that every agent and application in a company can draw from, including cross-system relationships and curated rules that no single user's view would contain. Existing Amazon Quick users will gain access to it once AWS Context is enabled.

AWS Context's Three Design Choices

AWS makes three core design choices that AWS Context rests on. The first choice is that the graph improves from how agents use it. As agents query, AWS Context observes which sources produce correct results and which join paths are used. It then ranks sources by usage and propagates a discovery (a correct join path or a resolved schema ambiguity) from the agent that found it to the rest of the graph and the agents that consume it, without requiring a person to re-curate the graph each time. This is incremental refinement on top of the steward workflow, but humans still decide what gets promoted into production; the learning loop just tunes ranking and reuse. This decision comes with the same risk as any usage-weighted system, where heavily used is not the same as authoritative, and a popular-but-wrong join path can reinforce itself unless curation catches it. You can't fully delegate ranking to AWS Context, you still need to curate the graph from time to time.

The second choice is that the context layer is open and portable. AWS Context publishes its key metadata in Apache Iceberg format to Amazon S3 Tables, so you can query it with Amazon Athena, Amazon Redshift, Apache Spark, or any Iceberg-compatible engine. Plus, you can connect third-party catalogs into the same graph, and let agents reach it through agentic-search APIs and MCP tools whether they run on Amazon Bedrock AgentCore or on other MCP-compatible frameworks. The published Iceberg metadata is open and available for you to query, audit, or move. However, the inference that builds the graph, the agentic search that serves it, and the learning loop that improves it are managed AWS capabilities. Using this open format for the graph lowers the cost of reading and reusing your context elsewhere, but it does not make the graph's behavior reproducible outside of AWS. In our opinion, that's a decent trade-off for the benefit of having inference, search, and learning as capabilities managed by AWS rather than implementing them from scratch.

The third choice is that access is identity-aware by default. Every query is designed to inherit the calling user's AWS IAM and AWS Lake Formation permissions, so an agent can see and traverse only the relationships its identity is authorized to reach. Since access runs through identity, every interaction is auditable with controls your security team likely already uses. Often the hardest question about putting an agent into production is what data it can reach and under whose authority. Answering both through existing identity infrastructure is the simplest implementation.

How Amazon S3 Annotations and AWS Glue Support Context

AWS Context did not ship alone. At the storage layer, Amazon S3 annotations are generally available in all AWS Regions, including the China Regions. They let you attach up to 1,000 named annotations to a single Amazon S3 object, each up to 1 MB, for as much as 1 GB of context per object, in JSON, XML, YAML, or plain text. Annotations are mutable and move with the object through copy and replication, so the context does not drift out of sync the way a separate database would. This also enables S3 Metadata to flow into a managed Iceberg table you can query with Amazon Athena or any Iceberg engine. One cost detail: annotation storage is billed at Amazon S3 Standard rates even when the underlying object sits in a colder storage class like Infrequent Access.

At the catalog layer, business context and semantic search for AWS Glue Data Catalog is now in preview. The feature lets you enrich tables, views, and columns with business descriptions, glossary terms, and custom metadata. You can find data by meaning through a new AWS Glue Search API, and attach skill assets that point agents to runbooks, query patterns, and usage rules held in places like Amazon S3, Git, or wikis.

At the graph layer, AWS Context synthesizes those signals into the organization-wide graph agents query at runtime.

The table below describes each piece, status, and what it lets you do today, so you can separate what to pilot now from what to plan for.