AWS Context Turns Enterprise Knowledge Into Reusable Agent Intelligence
Agents struggle when the data they need is scattered across data lakes, warehouses, business applications, and conversations that were never captured. The issue is a model missing business context, and Amazon Web Services is right to focus on it. AWS Context is built to make that context reusable and governed at runtime.
How AWS Context Turns Scattered Data Into Shared Agent Intelligence
AWS Context is a managed knowledge graph service. The service scans a customer’s existing catalogs, data lakes, warehouses, and unstructured stores, infers the relationships between them, and exposes that graph to AI agents at query time through an agentic search API and Model Context Protocol tools.
Instead of an agent guessing which table joins to which, or an engineer hand-coding that logic into every agent’s system prompt, the agent asks the graph and gets back ranked, governed context: entities, relationships, business rules, and usage patterns.
The Business Impact: Context at Enterprise Scale
The same graph that powers Amazon Quick now extends across all enterprise data sources, putting shared metadata in front of every consumer, including AI agents.
Three roles interact with the system. Agent builders consume the graph. Data platform teams author and promote it. Data stewards define what the relationships and business rules actually mean. According to AWS, the governance step does not disappear just because the organization is small. Someone still must review inferred relationships before they go into production, and someone still has to decide what counts as a trusted business rule versus a coincidence derived from the data.
Three components support AWS Context:
- Glue Data Catalog business context and semantic search: In preview, Glue Data Catalog can add glossary terms and custom metadata to tables, views, and columns so people and agents can search by meaning, not just by table name.
- Glue Data Catalog skill assets: These references to external files, such as runbooks or markdown guides, explain how an agent should use a dataset correctly, not only where the data resides.
- Amazon S3 annotations: Now generally available, these annotations let customers attach up to 1 GB of mutable, queryable business context to any S3 object, stored in Iceberg format and automatically indexed into a queryable table.
AWS built AWS Context by expanding two systems already used inside Amazon Quick. Amazon Quick is AWS’ enterprise AI assistant for finding information and completing work across approved business data.
- Structured asset mapping: This system maps relationships across structured assets, such as datasets and dashboards.
- Personal knowledge graph: This system builds a graph from unstructured signals, such as people, projects, and messages.
AWS says its internal graph has roughly 10 million nodes and handles more than 2.5 million queries a day. The impact is that AWS Context could make enterprise agents easier to scale by giving them a shared, governed understanding of business data instead of forcing each team to rebuild that context one agent at a time
AWS also reports up to 29 percentage points of accuracy improvement and up to 10x better token efficiency when agents use this context. These claims are directionally important because they point to a real business issue: agents become expensive and unreliable when they have to rediscover context one workflow at a time. Customers should test AWS Context in their own environment to see whether they can achieve AWS’ reported gains in accuracy and token efficiency.
AWS Context Reduces Repeat Work Across Every Agent
AWS Context attacks one of the least scalable parts of enterprise agent adoption. Without a shared context layer, engineering teams have to teach each new agent the same business meaning, relationships, and rules from scratch.
This increase in repeated engineering work also increases the chance that different agents will answer the same question differently. AWS says this setup work can take weeks for each agent when teams do not use a reusable context service. If AWS Context works as described, its value is reducing reinvention and improving retrieval.
Who Owns the Context Layer After AWS Builds It?
AWS Context involves three groups:
- Agent builders use the graph so their agents can find the right business context.
- Data platform teams build, review, and publish the graph.
- Data stewards define what business terms, rules, and relationships mean.
AWS can provide the service, but customers still own the business meaning. Someone must confirm which relationships are correct and which business rules and data patterns are reliable enough to govern an agent’s behavior.
AWS Context also gets security right, using the identity and access rights of the person or agent making the request. That means an agent should only see the data that user is allowed to see, and each access can be tracked through the customer’s existing controls. For organizations worried about what agents can touch, this may be more important than the accuracy claims.
AWS Context Adds a Feedback Loop to Familiar Data Catalog Ideas
AWS Context builds on familiar ideas from data catalogs and semantic layers. These approaches already help companies organize data and define business terms. AWS extends that foundation with a feedback loop: agents use the graph, AWS Context observes which sources and join paths lead to better answers, and that learning can improve future responses. If customers can validate this in their own environments, the learning loop may become the most differentiated part of the service.
The graph is also designed to be portable. AWS says its metadata can be stored in open Iceberg tables on Amazon S3 and queried through Athena, Redshift, or other Iceberg-compatible engines. AWS also says agents built on Bedrock AgentCore, Amazon Elastic Kubernetes Service, or other Model Context Protocol–compatible frameworks can use the service. That matters because customers will want to know whether they can use AWS Context without locking every agent workflow into AWS. This claim should be tested before customers rely on it.
Our Take
AWS Context is best understood as an effort to move agent readiness from individual project work to shared enterprise infrastructure. The companies most likely to benefit are those already investing in data catalogs and governance, because they have the organizational muscle to keep a context layer trusted over time.
Customers should not treat AWS Context as a shortcut around governance. Buyers should ask how much human review the graph needs after creation, including how much oversight is targeted specifically at validating that the relationships AWS Context infers between data sources are actually true and how access controls hold up when agents operate across systems. They should also ask whether the graph, metadata, and skill assets are portable if the organization runs agents outside the AWS ecosystem.
Our view is that AWS Context addresses a real gap in enterprise AI, but its success will depend less on the elegance of the graph and more on customer discipline. The advantage is reusable, governed context that can improve as agents use it. The consideration is whether organizations have the stewardship and testing discipline to keep that context accurate. For chief information officers, the real question is whether AWS Context can scale without becoming another system that data teams must constantly clean up.
If you are running Snowflake or Databricks on AWS, you need to determine how Databricks Unity Catalog with Genie Ontology and Snowflake’s five-layer agent context framework, including Semantic Views, Horizon Catalog, and Cortex Sense, should be used with AWS Context. Otherwise, you may end up managing several contexts for AI agents. Ideally, the three vendors will develop an enterprise context integration method, possibly using the open Iceberg format as the foundation. Until then, make sure your context is not conflicting. For example, you should have the same enterprise-wide definition of customer, product, patient, student, and other core business terms.