AWS Context: What a Self-Learning Graph Means for SMBs

By Lazar Milicevic · Published November 11, 2026 · 9 min read

Your agents keep writing SQL against the wrong table, joining on the wrong key, or ignoring the business rule that "active customer" means a paid invoice in the last 90 days. Somebody has to maintain the layer that tells agents what your data means, and right now that somebody is usually you. AWS just announced a service that aims to build and maintain that layer automatically, so it's worth understanding what it does, what it doesn't, and what you can build today.

What AWS actually announced

AWS announced a three-product "context intelligence stack" at AWS Summit New York on June 17, 2026. The centerpiece is AWS Context, a knowledge graph that sits between your data stores and your AI agents. The other two pieces are Amazon S3 Annotations (generally available) and skill assets in the AWS Glue Data Catalog (preview).

The problem AWS is targeting is real. As VentureBeat framed it, building a context layer between enterprise data and agents is bespoke work, and there's no standard service that automates or maintains those graphs over time. Every team that ships agents against real data ends up hand-building some version of it: a semantic layer, a glossary, a set of few-shot SQL examples, a pile of prompt instructions that rot.

Here's what each piece does:

One caution up front: the AWS blog labels AWS Context "Coming soon," not generally available. Some sources describe it as if it's already available, but AWS lists it as "coming soon"; the "preview" label applies to the Glue skill assets. I found no published pricing, Regions, or confirmed release date, so if you're planning a budget around it, you can't yet. Check the current AWS pages before you commit to anything.

The part that's new: a graph that learns from agent usage

Most context layers are static. A human writes definitions, and they drift as the schema changes. AWS's pitch is that the graph observes how agents use it and improves from that.

According to the AWS blog post, as agents query the graph, it tracks three things:

1. Which sources give correct results.
2. Which join paths agents rely on.
3. Which curated rules get applied.

It then ranks sources by actual usage. And what one agent learns is shared: when one agent finds a correct join path or resolves a schema ambiguity, other agents pick it up without a human re-curating the graph. Swami Sivasubramanian, AWS VP of Agentic AI, put the pitch in his keynote as agents getting smarter without having to rebuild anything from scratch.

That's the difference between a data catalog and a context layer. A catalog describes data. A context layer records how the data is used successfully, and feeds that back.

Notice what this is not. VentureBeat's headline says "not manual curation," but AWS's own documentation says humans stay in the loop: data stewards review inferred relationships in the console, promote them to production, and attach business definitions and usage rules. The accurate version is that you don't have to manually re-curate the graph every time agents learn something new. You still approve what becomes authoritative. That's the right design, and I'd be suspicious of any vendor claiming otherwise.

How it works under the hood

A few architectural details from the AWS material matter if you're evaluating this for real use:

• Access path. Agents query through agentic search APIs and MCP tools. They can be built on Amazon Bedrock AgentCore, deployed on Amazon EKS, or run on any MCP-compatible framework.
• Permissions. Per VentureBeat, every query inherits the calling user's IAM and Lake Formation permissions. This is the detail I'd weigh most heavily. A shared, learning graph is a data-leak risk if it surfaces relationships a given user shouldn't see; inheriting the caller's permissions is the right answer.
• Metadata format. Metadata is published in Apache Iceberg format to Amazon S3 Tables, so you can query it with Athena, Redshift, Spark, or any Iceberg-compatible engine. That's good for portability and auditing: the graph's output isn't locked in a black box.
• Lineage. AWS Context extends the knowledge graph technology behind Amazon Quick, which AWS says already processes millions of requests per day. The move is from a personal graph to an organizational one.
• Third-party data. It's designed to connect to third-party catalogs, so context from systems outside AWS can come into the same graph.

Two open questions: how well it handles documents and unstructured sources (coverage of this varies between outlets, so check the current AWS documentation for what is in scope), and performance. Analyst Holger Mueller of Constellation Research flagged performance as the main concern, especially for transactional data.

The open-source piece you can run now: Context Ontology Accelerator

If you can't wait for AWS Context, there's something concrete to look at. On July 31, 2026, AWS released the Context Ontology Accelerator as an open-source project under Apache 2.0 on GitHub. To be clear, it's an open-source project, not a managed service, despite the URL slug.

The workflow: AI drafts the ontology, and domain experts review and approve every element. AWS says the ontology capability will become a fully managed feature native to AWS Context.

The initial release uses:

• Amazon Neptune as the graph store
• Amazon OpenSearch Serverless as the vector store
• Foundation models hosted on Amazon Bedrock
• An included MCP server that agents consume

Before you deploy it, know the cost caveat. Neptune and OpenSearch Serverless are not free at idle, so an always-on deployment carries a standing monthly cost. Check current Neptune and OpenSearch Serverless pricing on the AWS pricing pages and estimate your own deployment. For a solo operator or a five-person team, an always-on graph database plus a vector store may cost more than the problem it solves.

Do you need a managed context graph at your size?

Probably not yet, and that's the honest answer for most readers of this blog. Here's how I'd decide.

You likely need a graph-based context layer if:

• Multiple agents (or multiple teams' agents) hit the same data and keep rediscovering the same join paths and rules.
• You have dozens-to-hundreds of tables across several systems, and the "what does this column mean" knowledge lives only in someone's head.
• You need per-user permission enforcement on what agents can see.

You likely don't if:

• You have one or two agents against a handful of tables. A well-written schema description, a short glossary file, and a few verified example queries will outperform an expensive graph you have to operate.
• Your data mostly lives in SaaS tools (CRM, accounting, helpdesk) rather than a lake. The context you need is in tool schemas and a few business rules.

Context engineering at small scale is mostly boring. The biggest wins I see come from a one-page definitions doc ("active customer = paid invoice in last 90 days"), explicit join keys, and a validation step that rejects agent-written queries touching the wrong tables. A graph automates that when it outgrows a document, not before.

A minimal version you can build today

You can approximate the core idea, capture what works and feed it back, without any AWS service. Here's the pattern: a small store of verified "context facts" that agents read at runtime and that a human promotes after review. This mirrors the AWS design (agents propose, stewards approve) at tiny scale.

# context_store.py - minimal "learn from agents, human approves" pattern
import json, sqlite3, time

db = sqlite3.connect("context.db")
db.execute("""
CREATE TABLE IF NOT EXISTS context_facts (
  id INTEGER PRIMARY KEY,
  kind TEXT,            -- 'join_path' | 'business_rule' | 'source_rank'
  payload TEXT,         -- JSON
  status TEXT DEFAULT 'proposed',   -- proposed | approved | rejected
  uses INTEGER DEFAULT 0,
  successes INTEGER DEFAULT 0,
  created REAL
)""")

def propose(kind, payload):
    db.execute("INSERT INTO context_facts (kind, payload, created) VALUES (?,?,?)",
               (kind, json.dumps(payload), time.time()))
    db.commit()

def record_outcome(fact_id, success: bool):
    db.execute("UPDATE context_facts SET uses=uses+1, successes=successes+? WHERE id=?",
               (1 if success else 0, fact_id))
    db.commit()

def approved_context(kind=None):
    q = "SELECT id, kind, payload FROM context_facts WHERE status='approved'"
    rows = db.execute(q + (" AND kind=?" if kind else ""), (kind,) if kind else ()).fetchall()
    return [{"id": r[0], "kind": r[1], **json.loads(r[2])} for r in rows]

Expose approved_context() to your agents through an MCP tool, have agents call propose() when they find a join path that worked, and review the proposed rows weekly. Rank by successes / uses the way AWS ranks sources by observed usage.

# weekly review: what did agents learn that's worth promoting?
sqlite3 context.db "SELECT id, kind, payload, uses, successes
  FROM context_facts WHERE status='proposed' AND uses >= 3
  ORDER BY (successes*1.0/uses) DESC LIMIT 20;"

Two rules keep this from rotting: never auto-promote (a human approves, always), and log which approved fact each query used, so when an answer is wrong you can trace it to a specific fact and retire it.

What to watch before you bet on it

If you're an AWS-heavy shop, this is worth tracking, but I'd treat it as unproven until these land:

1. A real availability date and pricing. Neither is published as of this writing; Atlan's overview and the AWS blog both describe it as "coming soon." Check the current AWS pages for any announcement before you plan around it.
2. Benchmark or accuracy data. "Agents get smarter" is a claim until someone measures it on a task you care about.
3. Performance on transactional data. Mueller's concern is the right one to test on your own workloads.
4. Cross-system reach. Third-party catalog connectivity is promised in design; verify which catalogs are supported before you assume your non-AWS systems are covered.
5. Governance of shared learning. Shared learning across agents is the headline feature and the main risk. Ask how a wrong inferred relationship gets detected, quarantined, and rolled back.

The broader signal matters more than the product: the context layer is becoming a first-class infrastructure category, and the ideas (usage-ranked sources, shared learning, steward approval, permission inheritance) are portable even if you never touch AWS.

Where this leaves a small team

The pattern behind AWS's auto-learning context graph is worth borrowing even if you never use the product: a governed store of definitions, join paths, and business rules that agents read at runtime, a feedback loop that records what worked, and a human approval step before anything becomes authoritative. At small-team scale, my recommendation is usually a lightweight store and an MCP server rather than a graph database, because the operating cost and complexity of Neptune-class infrastructure rarely pays off below a certain number of agents and data sources.

If you're deciding between a hand-built context layer, an open-source ontology tool, or waiting for a managed service, work through it against your actual data and agents first: count your tables, list the business rules agents keep getting wrong, and check current AWS pricing pages before committing to anything.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.