Your AI Agents Are Making Decisions Without Context: How AWS Context Fixes That with Knowledge Graphs
AWS Context is a new service that automatically maps relationships across your data into a knowledge graph, giving AI agents governed access to business rules, data relationships, and domain knowledge at runtime. Learn what it is, how it works, and how to get started.
120XSAP 12XAWS 15xAZURE 12xORACLE 10XSCRUM 11XOCI 12XMS 5XSECURITY 2XSOLARIS 2XDB2
The Problem Every Enterprise Hits at Scale
You built an AI agent. It answers questions, runs tools, and looks impressive in a demo. Then you put it in front of a real user who asks: "What is the churn risk for our top three accounts this quarter?"
The agent has no idea. It does not know which accounts are "top three." It does not know what your organization defines as churn risk. It does not know that Account A switched billing contacts last week, or that Account B filed three support escalations in the past month.
Your agent is smart but clueless. It has intelligence without context.
This is the gap AWS Context is designed to close.
What is AWS Context?
AWS Context is a new service announced at the AWS Summit New York City on June 17, 2026. It automatically maps the relationships across your existing data into a knowledge graph and provides agentic search so AI agents in your organization can access governed data relationships, business rules, and domain knowledge at runtime.
Think of it as giving your agents an organizational brain. Not a static database they query, but a living graph that learns from how your agents interact with it.
Here is what makes it different from building your own knowledge graph:
- Automatic relationship mapping: You point it at your data sources and it infers connections between entities across systems.
- Identity aware governance: Every query inherits the calling user's IAM and Lake Formation permissions. An agent can only see what its identity is authorized to access.
- Learning from usage: As agents query the graph, it observes which sources produce correct results and which join paths work. It ranks sources by actual usage and shares these learnings across your organization.
- Open and portable: All metadata is published in Apache Iceberg format to Amazon S3 Tables. You can query it with Amazon Athena, Amazon Redshift, Apache Spark, or any Iceberg compatible engine.
A Real World Example: The Sales Agent That Finally Understands Your Business
Let us walk through a practical scenario.
Without AWS Context:
A sales representative asks their AI agent: "Prepare me for my meeting with the customer tomorrow."
The agent searches through emails, finds some threads, maybe pulls a CRM record. But it does not know that:
- The customer's infrastructure team filed 12 support tickets last month (from your support system)
- Their contract renewal is 60 days away (from your billing system)
- A competitor ran a proof of concept with them last quarter (from a Slack thread)
- The decision maker changed roles two weeks ago (from LinkedIn data in your CRM)
Each of these facts lives in a different system with no connection between them.
With AWS Context:
The same question hits the knowledge graph. AWS Context already mapped the relationships:
- Customer entity connects to support tickets (relationship: filed_by)
- Customer connects to contract ID 4421 (relationship: active_agreement, attribute: renewal_date)
- Customer connects to competitor evaluation (relationship: evaluated, source: Slack)
- Decision maker connects to new role (relationship: role_change, timestamp: 2 weeks ago)
The agent returns a pre meeting brief with all four insights, prioritized by relevance to the upcoming meeting.
This is not a hypothetical architecture. AWS describes this exact pattern in their announcement blog, noting that they built Customer Agent and Knowledge Engine (CAKE) internally using this approach. CAKE coordinates specialized retriever tools querying knowledge graphs in Amazon Neptune, metrics in Amazon DynamoDB, documents in Amazon OpenSearch Service, and external market data using a web search API, delivering customer insights through natural language queries.
How AWS Context Works Under the Hood
The Knowledge Graph Layer
AWS Context builds on the same knowledge graph technology that powers Amazon Quick, where hundreds of thousands of users interact daily with a production knowledge graph that catalogs datasets, dashboards, and metadata. According to the AWS announcement, that graph already processes millions of requests per day.
The graph contains three types of information:
- Structural metadata: Table schemas, column types, relationships between tables across data sources
- Business context: Definitions, glossary terms, usage rules, and domain knowledge that data stewards add
- Behavioral patterns: Which join paths agents use successfully, which sources produce correct results, and which queries fail
Integration Points
AWS Context integrates with:
Service | Integration |
|---|---|
AWS Glue Data Catalog | Enriches tables, views, and columns with business descriptions, glossary terms, and skill assets |
Amazon SageMaker Unified Studio | Connects ML workflows to governed data context |
AWS Lake Formation | Enforces permissions at the graph query level |
Amazon Bedrock AgentCore | Agents query the graph through agentic search APIs and MCP tools |
Apache Iceberg | All metadata published in open format for portability |
Skill Assets: Teaching Agents How to Use Your Data
One of the most practical features is Skill Assets in Glue Data Catalog. Data producers can create skill assets that reference URIs to files such as AI skills, guide markdown files, and team runbooks hosted in any location including S3, Git repositories, and wikis.
For example, your data engineering team writes a markdown file explaining:
- The grain and scope of your revenue table
- Common query patterns and best practices
- Required filters (always filter by region before aggregating)
- Join keys (use customer_id, not account_id, for cross-system joins)You attach this skill asset to the revenue table in Glue Data Catalog. Now every agent that discovers this table through AWS Context also gets the instructions on how to use it correctly.
Getting Started: Three Steps to Your First Knowledge Graph
Step 1: Connect Your Data Sources
AWS Context connects to your existing data through AWS Glue Data Catalog. If you already catalog your data in Glue, you are most of the way there. The service ingests metadata from:
- Amazon S3 (including the new S3 Annotations feature for attaching up to 1 GB of context per object)
- Amazon Redshift
- Amazon RDS
- Amazon DynamoDB
- Third party catalogs
Step 2: Curate and Govern
Data stewards review inferred relationships through the console, promote them to production, and attach domain specific knowledge. This is where the human expertise layer gets encoded:
- Business definitions ("revenue" means recognized revenue, not bookings)
- Usage rules ("always join on fiscal_quarter, not calendar_quarter for finance reports")
- Access governance through existing Lake Formation permissions
Step 3: Connect Your Agents
Agents query the graph through:
- Agentic search APIs for direct programmatic access
- MCP tools for agents built on Amazon Bedrock AgentCore, Amazon EKS, or any MCP compatible framework
- AWS Agent Toolkit which contains default skills for Glue Data Catalog, Amazon Athena, and S3 Tables
Developers can connect any MCP compatible agent using the remote, fully managed AWS MCP server, or install the aws-data-analytics plugin for Claude Code, Cursor, and Amazon Kiro.
Why This Matters for Your Team
If you are a developer, architect, or cloud practitioner supporting customers, here is what this enables:
For customers building AI agents: Instead of hard coding business logic into every agent prompt, they encode it once in the knowledge graph and every agent benefits. When one agent discovers a correct join path, other agents pick it up automatically.
For data governance teams: Every agent query is identity aware and auditable. Security and compliance teams can verify what an agent accessed and under what authority using the same IAM controls they already manage.
For platform engineering: No infrastructure to provision or retrieval pipelines to build. The context layer runs as a managed service with open standards (Iceberg) for portability.
What to Do Next
- Assess your data catalog maturity: If you are not using AWS Glue Data Catalog yet, start there. AWS Context builds on top of it.
- Identify your high value join paths: Which cross system relationships do your analysts manually navigate today? Those are the first candidates for the knowledge graph.
- Start writing skill assets: Document the tribal knowledge your team carries about how to use specific datasets. Even before AWS Context is generally available, these markdown files become reusable instructions for any agent.
References
- AWS Summit NYC 2026: New AI Agent Innovations (June 17, 2026)
- Top announcements of the AWS Summit in New York, 2026 (June 17, 2026)
- Build unified intelligence with Amazon Bedrock AgentCore (February 18, 2026)
- The AWS MCP Server is now generally available (May 6, 2026)
About the Authors
Sekh Mohammad Warish is a Senior Technical Account Manager at AWS, supporting customers across SAP, GenAI, and cloud modernization. With 120+ IT certifications including 12 AWS certifications, he helps customers adopt emerging technologies and build production-ready solutions on AWS. Connect on LinkedIn .
Nitish Tipparaju is an Enterprise Support Manager at AWS, leading technical account teams that drive GenAI adoption and operational excellence for customers. He co-leads GenAI upskilling programs and brings hands-on experience helping organizations build their first AI agents on AWS.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article