Most businesses sitting on years of data have a quiet problem that only becomes loud the moment they try to put an AI agent into production. The information an agent needs to give a correct answer is real, but it is spread across a data warehouse, a handful of databases, an S3 data lake, a pile of documents, and the institutional knowledge that lives only in people’s heads. An agent that cannot see how those pieces connect will guess, and a confident wrong answer about a customer balance or an inventory figure is worse than no answer at all. At the AWS Summit in New York City on 17 June 2026, AWS announced a service aimed squarely at this gap, called AWS Context, and it is worth understanding even if you are not building agents yet.
In short, AWS Context is a new service that automatically maps the relationships across your existing data into a knowledge graph and gives AI agents a governed way to search it at runtime. Rather than asking every agent to rediscover how your tables join, what your business terms mean, and which data source is authoritative, you build that understanding once into a shared graph, and every agent in the organisation draws from it. Crucially, each query inherits the calling user’s IAM and AWS Lake Formation permissions, so an agent only sees the relationships its identity is allowed to see, and every access is auditable. The service was announced as coming soon, so the time to understand it is now, before your first agent project hardens around a worse design.
Why Context Is the Real Bottleneck for Business AI
The popular story about AI agents is that the model is the hard part. In practice the model is rarely the thing that fails first. What fails is context. An agent can be perfectly capable of writing a query, but if it does not know that “revenue” in the finance schema excludes refunds while “revenue” in the sales dashboard includes them, it will produce a number that looks plausible and is wrong. Multiply that across dozens of tables, several systems, and a few years of undocumented business rules, and you get the situation most scale-ups find themselves in when an early agent demo meets real data.
AWS frames this well by describing context as the data lake for AI agents. The raw material is already there in your warehouses, lakehouses, databases, streams, and documents. The missing layer is the map that explains how all of it fits together and which parts can be trusted. Until that map exists, every agent project quietly rebuilds a fragment of it through prompt engineering and hand written instructions, and those fragments drift apart over time. AWS Context is an attempt to make that map a first class, governed asset rather than something scattered through a hundred prompts.
What AWS Context Actually Does
AWS Context reads across your existing data and infers the relationships between assets, then presents those inferred relationships to data stewards through a console where a human can review them, promote the good ones to production, and attach domain knowledge such as business definitions and usage rules. This matters because a knowledge graph that nobody curates becomes a liability, and a graph that requires hand building every edge never gets finished. The design tries to sit in between, using AI to propose connections and people to approve them.
The technology underneath is not brand new, which is reassuring. AWS Context extends the same knowledge graph technology that already powers Amazon Quick, where AWS says hundreds of thousands of users interact daily with a production graph that processes millions of requests a day. The shift here is from a personal graph to an organisational one, a shared context layer that applications and agents across the company can use. It integrates with AWS Glue Data Catalog, Amazon SageMaker Unified Studio, and AWS Lake Formation, so the governance and cataloguing tools many teams already run become the way you manage the graph.
One detail that will appeal to anyone who has been burned by lock in is that the key metadata is published to Amazon S3 in Apache Iceberg format on S3 Tables. That means you can query your context with Amazon Athena, Amazon Redshift, Apache Spark, or any Iceberg compatible engine, and you can audit it or migrate it without asking permission from a proprietary system. AWS Context is also designed to connect to third party catalogues, so context from systems outside AWS can feed the same graph, and agents reach it through agentic search APIs and MCP tools whether they run on Amazon Bedrock AgentCore, on Amazon EKS, or on any MCP compatible framework.
The Part That Should Matter Most to a Founder: Governance
The capability that turns this from an interesting research idea into something you can actually put in front of customer data is identity aware access. Every query an agent makes through AWS Context is designed to inherit that user’s IAM and Lake Formation permissions. An agent acting on behalf of a junior support rep cannot traverse relationships into finance data the rep was never allowed to see. Because access runs through identity rather than around it, every interaction is auditable with the same controls you already rely on, so your security and compliance people can answer the two questions that always come up, namely what did the agent reach and under whose authority.
For a founder or engineering leader, this is the difference between a board level yes and a board level no. The objection to agents in regulated or sensitive environments has never really been about whether the model is clever enough. It has been about whether you can prove an agent did not quietly read something it should not have. A context layer that enforces existing permissions and logs every access is how you get past that objection without building a bespoke approval system of your own.
It Gets Smarter the More Your Agents Use It
There is a second feature worth calling out because it changes the economics of maintaining the graph over time. AWS Context observes how agents actually use it. As agents query the graph it notices which sources produce correct results, which join paths get relied on, and which curated rules get applied, then it ranks sources by real usage and shares those learnings across the organisation. When one agent works out a correct join path or resolves an ambiguity, other agents inherit that without a human re-curating anything.
In a small team this compounding effect matters more than it might at a large enterprise, because you do not have a dedicated data platform group to keep a catalogue current. A context layer that partly maintains itself from usage is the kind of leverage that lets a lean team run something that would otherwise need headcount you do not have.
What This Means Alongside the Rest of the Summit
AWS Context did not arrive alone. At the same Summit AWS previewed business context and semantic search for AWS Glue Data Catalog, including a new search API and a concept called skill assets that let data producers attach runbooks, query patterns, and usage rules to data so agents stop being re-taught the same caveats one prompt at a time. AWS also made Amazon S3 annotations generally available, which lets you attach up to one gigabyte of rich, queryable business context directly to an S3 object, stored as an Iceberg table and moving with the object through copy and replication. Taken together these point at a clear direction of travel. AWS is building the plumbing so that the context an agent needs lives with the data, is governed by the permissions you already set, and stays in open formats you can leave with.
What to Do About It
You do not need to wait for general availability to benefit from the thinking behind AWS Context, and frankly the preparation work is where most of the value is. Start by getting your data catalogue in order, because AWS Context builds on AWS Glue Data Catalog and Lake Formation, and a graph inferred from an undocumented, ungoverned estate will simply surface that mess faster. Write down the business definitions that currently live in people’s heads, because those are exactly the curated rules the graph will let you attach, and they are useless to an agent while they remain tribal knowledge. Tighten your IAM and Lake Formation permissions now, because identity aware agent access is only as good as the identities and grants underneath it. Do these three things and you will be ready to adopt AWS Context the day it lands, and you will have a cleaner, safer data estate even if you never turn an agent on.
If your data is scattered across accounts, your catalogue is thin, or you are not confident you could prove what an AI agent is allowed to touch, that is exactly the groundwork worth getting right before you build. HAZERCLOUD helps UK, European, and US businesses get their AWS data foundations, governance, and permissions into shape so that agents and analytics can be trusted rather than feared. Book a free consultation and AWS data readiness assessment at https://hazercloud.com/contact/ and we will help you turn a scattered estate into something your next AI project can actually stand on.
