AWS Context skips RAG. Continuum validates CVEs itself.

Amazon's pitch at the AWS Summit in New York was unusually blunt: today's AI agents fail in production not because the models are weak, but because the agents don't know your business — and the code they generate is piling up security debt faster than anyone can clear it.

AWS's diagnosis: why an AI agent produces confident, wrong answers

An AI agent produces confident-but-wrong answers because it can call models and tools but has no map of an organization's data relationships, ownership, or authoritative sources — so it guesses, and guesses fluently. That was AWS's framing on June 17, 2026 at the AWS Summit in New York, where it named two gaps holding back enterprise agents and launched a service against each: missing business context (AWS Context) and inadequate security (AWS Continuum) .

The first gap is context. An agent can invoke a tool or query a database, but without governed relationship data it cannot tell which record is authoritative, who owns a system, or which business rule applies. AWS describes the result as "confident but incorrect" recommendations — the model fills the gap with a plausible answer rather than a correct one (source: The Decoder, 2026-06). Context targets that directly by exposing organizational relationships through a knowledge graph at runtime.

The second gap is security velocity. AI now writes code faster than human teams can triage what it produces, and the unreviewed output accumulates as CVE backlogs. AWS positions Continuum to drain those backlogs at machine speed — continuous discovery, prioritization, exploit validation, and remediation — rather than waiting on human review cycles (source: About Amazon, 2026-06).

One framing detail matters for developers evaluating this: neither service is new infrastructure. Both sit atop Amazon Bedrock AgentCore, which has been generally available since October 13, 2025 and supplies the runtime, memory, and identity primitives agents already run on . Context and Continuum are application-layer additions to that stack, not replacements for it — a distinction that shapes how, and whether, you'd adopt them.

How AWS Context maps an organization's relationships into a graph

AWS Context is a managed knowledge-graph service that automatically maps the relationships across a company's existing data and exposes them to agents through "agentic search" at runtime . Instead of hand-built retrieval pipelines, an agent queries the graph directly and pulls governed organizational relationships, business rules, and domain knowledge — the missing layer AWS blames for "confident but incorrect" recommendations .

Quick Answer: AWS Context ingests heterogeneous sources — databases, CRM, documents, emails, and Slack — and infers their relationships into a knowledge graph automatically, with no manual ETL or chunking. Agents reach it via "agentic search," retrieving only data their identity permits because business rules and access controls are applied at ingestion .

The ingestion model is what distinguishes it from a hand-rolled RAG stack. Context ingests and infers relationships across structured and unstructured sources — databases, CRM systems, documents, emails, and chat tools such as Slack — without requiring you to write schema mappings, ETL jobs, or chunking logic . For developers who have maintained embedding pipelines and re-chunking strategies by hand, that is the practical pitch: AWS positions Context as a managed alternative that needs no retrieval-pipeline development or infrastructure provisioning .

Governance is enforced at the source rather than bolted on afterward. Context applies business rules and access controls during ingestion, so an agent only ever sees governed data — it retrieves what its identity is permitted to see, with no separate authorization layer to wire up between the agent and the graph . In practice that collapses two jobs developers usually treat separately — building the retrieval index and enforcing row- or document-level access — into one managed boundary.

AWS also frames Context as something that improves with use. The graph learns from agent query patterns over time, which is how AWS summarizes its value:

"Context is what makes your agent's tenth decision better than its first." — AWS, AWS Summit New York 2026 (source: AWS News Blog)

Treat that as a claim to verify rather than a delivered result. AWS has disclosed no benchmarks for graph quality or retrieval accuracy, and Context itself is described only as "coming soon," with no general-availability date . The architecture is plausible and the developer ergonomics are attractive, but "learns from query patterns" is a behavior you'd want to measure on your own data relationships before trusting it for any decision an agent acts on.

The technical internals: Apache Iceberg, S3 Tables, and Glue Catalog

AWS Context is not a net-new research effort: it runs on the same knowledge-graph technology that already powers Amazon Quick, repackaged as a managed service for agents . That reuse matters for evaluation. You are betting on a graph engine with production mileage rather than a demo, which lowers the "does the core technology work" risk and shifts the open questions toward your data and your access rules.

The storage layer is conventional AWS plumbing, which is the point. Context stores its metadata in Apache Iceberg format on S3 Tables and integrates with the AWS Glue Data Catalog for schema and lineage tracking . For a developer, that has practical consequences:

• Iceberg on S3 Tables means the graph metadata sits in an open table format you can query and version, not a black-box store you can only reach through the agent.
• Glue Data Catalog integration means schema and lineage come from the catalog you may already maintain, so the graph inherits column definitions and provenance instead of redefining them.
• Both choices keep Context inside the existing AWS lakehouse rather than introducing a separate system of record.

The deployment pitch is the absence of a pipeline. AWS positions Context as requiring no retrieval-pipeline development, no embedding infrastructure, and no vector store to provision — a managed alternative to a hand-built RAG stack . If you have built RAG before, that is the chunking, embedding, index-tuning, and re-embedding maintenance loop removed from your roadmap. The trade is the usual managed-service one: less control over how relationships are inferred and ranked, in exchange for not owning the retrieval plumbing.

The hard caveat is availability. As of June 2026, AWS Context is described only as "coming soon," with no general-availability date, no regional list, and no pricing disclosed . That is a meaningful gap against the rest of AWS's agent stack, where consumption pricing is already published. You can study the architecture now, but you cannot run a cost model or a regional latency test until AWS attaches numbers and a date to it.

Continuum's CVE lifecycle: prioritization, exploit validation, and targeted remediation

AWS Continuum is an AI-native security service that manages the full vulnerability lifecycle — discovery, prioritization, exploitability validation, and remediation — at machine speed, introduced as "AWS Continuum for code vulnerabilities" at the AWS Summit in New York on June 17, 2026 . Its central bet is that the bottleneck is no longer finding vulnerabilities but triaging them: it ranks findings by organizational context — business priorities, system dependencies, and risk profiles — rather than by abstract CVSS-style severity scores .

That reframing matters because a high CVSS number on a dependency that is unreachable in your deployment is noise, while a medium-severity flaw on an internet-facing service holding customer data is not. Continuum's stated mechanism for cutting false positives is exploit replication: before surfacing a finding, it attempts to reproduce the attack in an isolated, sandboxed environment to prove the vulnerability is actually exploitable in context . Treat that as a vendor claim — AWS has not published benchmarks on its false-positive rate or how sandbox fidelity holds up against production-only conditions.

Remediation is similarly targeted. Instead of generic "upgrade the library" advice, Continuum recommends the specific fix the CVE class calls for — a network-configuration change, a permission adjustment, or a code patch .

AWS frames the urgency around specialized security models outpacing human triage. The company cited Anthropic's "Claude Mythos" as able to surface vulnerabilities faster than teams can fix them — exactly the backlog Continuum is meant to drain .

"Specialized models like Claude Mythos can find vulnerabilities faster than teams can fix them" — AWS framing at the Summit, reported by CIO Dive. Treat as vendor positioning, not independent measurement.

Continuum does not stand alone. The AWS Security Agent now integrates with it and extends coverage from design to deployment, adding STRIDE-framework threat modeling, pull-request scanning, and IDE integrations . The practical reach is gated, though: as of June 2026, Continuum is available only in a gated preview to select pilot customers, with no pricing or general-availability date .

When Continuum acts without human approval: from supervised to independent operation

AWS Continuum does not begin as an autonomous remediation engine; it starts in a "learning mode" where every proposed fix requires explicit human sign-off before it executes . That supervised phase is the calibration window: teams watch what Continuum proposes — network-configuration changes, permission adjustments, or code patches — and judge whether its reasoning holds before they extend it any real authority. The escalation of trust is deliberate, not implicit.

From there, Continuum can graduate to an "enforcement mode" in which it applies remediations without per-action approval . The important detail for anyone evaluating this: the graduation threshold is customer-defined, not set by AWS. You decide which finding classes, which environments, and which risk profiles are eligible for hands-off remediation, and which still route through a human. That keeps the autonomy boundary under the operator's control rather than a vendor default.

The architecture is built to make that boundary auditable. AWS describes Continuum as carrying full explainability and auditability logs, plus the ability to preview rollbacks before any enforcement action runs . In practice that means a reviewer can see why a fix was selected, trace what it touched, and inspect the proposed undo path before committing — the safety scaffolding you would want before letting any system change production security posture on its own. It is worth noting these are vendor-stated properties; AWS has published no independent validation of the rollback or audit guarantees yet .

Continuum is also model-agnostic by design . AWS framed the launch against the rise of specialized security models, citing Anthropic's "Claude Mythos" as an example of an LLM that can surface vulnerabilities faster than teams can fix them — the backlog Continuum is meant to drain . Read that as positioning, not architecture. Claude Mythos is cited as an illustration of the threat landscape, not as Continuum's required or exclusive engine, and the reference appears in trade reporting rather than AWS product documentation. The takeaway: the model layer is swappable, and the autonomy controls — learning mode, customer-set thresholds, rollback preview — are what actually govern how far Continuum is allowed to act.

Where AWS Context and Continuum layer onto the existing AgentCore stack

AWS Context and Continuum do not replace AgentCore primitives — they operate at a wider scope. Amazon Bedrock AgentCore, generally available since October 13, 2025, ships per-agent infrastructure: Runtime, Memory, Observability, Identity, Gateway, Browser, and Code Interpreter . Two of those overlap the same context and security gaps the new services target, but at a different abstraction level.

AgentCore Memory is a managed memory layer per agent instance: short-term memory captures turn-by-turn interactions within one session, organized by actor ID and session ID, while long-term memory extracts cross-session facts and summaries by namespace, with IAM able to restrict retrieval by namespace path . That is per-agent state. AWS Context is org-wide relationship mapping across databases, CRM, documents, and chat — different scope, not a competing feature .

The same split holds on security. AgentCore Identity manages credentials — AWS SigV4, OAuth 2.0, and API keys through a KMS-encrypted token vault, with provider templates for Google, GitHub, Slack, Salesforce, and Atlassian Jira . Continuum handles vulnerability triage. Both sit near the identity and access layer, but Identity issues and stores tokens while Continuum reasons about exploitability and remediation — adjacent, not redundant.

The clearest practical difference is pricing transparency. AgentCore publishes consumption rates; AWS Context and Continuum have disclosed none .

Context and Continuum were not the only Summit announcements. AWS said AgentCore Harness reached general availability, alongside a Bedrock Managed Knowledge Base, managed web search on AgentCore, and Strands improvements . Earlier, AWS made its DevOps Agent and Security Agent generally available on April 6, 2026, with the Security Agent now integrating with Continuum and adding STRIDE threat modeling, pull-request scanning, and IDE integrations . The pattern: GA primitives you can price and provision today, with two preview services layered above them whose economics remain unknown.

What AWS hasn't proved about either service — and the right questions to ask first

Neither AWS Context nor AWS Continuum has published a benchmark, and that absence should shape how you evaluate them. AWS describes Context as a knowledge graph that infers relationships across heterogeneous org data, but it has released no public figures on graph inference accuracy, relationship coverage gaps, or hallucination rates for agentic queries over complex schemas . For a service whose pitch is "your agent's tenth decision is better than its first," the missing number is precisely the one that matters: how often the graph is wrong, and how that error propagates into an agent's confident output.

Continuum has the same gap with higher stakes. Its central claim — replicating attacks in isolated, sandboxed environments to prove exploitability and cut false positives — is vendor-stated . No independent study has replicated or disputed the mechanism. Sandboxed replication is a credible idea, but "proves exploitability" is a strong assertion to take on trust from a service that begins in gated preview with no published true-positive or escape rates.

The headline productivity numbers deserve the same scrutiny. AWS cites a Signal65 study reporting 2.1x faster end-to-end agent development, 75% less infrastructure and integration time, and 5.2x faster cloud deployment . That research was commissioned by AWS, not independently conducted — vendor-supported evidence, not neutral measurement. Treat the multipliers as directional marketing until a third party reproduces them.

"Context is what makes your agent's tenth decision better than its first," AWS said of the service (source: AWS Summit NYC 2026 announcements) — a claim that only holds if the graph it learns from is accurate, which AWS has not yet shown.

Before either reaches a production roadmap, get answers to four concrete questions:

• AWS Context: a firm GA date and region list — it is still "coming soon" with no general-availability timeline .
• Continuum enforcement mode: failure-handling and a rollback SLA — it can preview rollbacks and graduate from human-approved learning mode to autonomous enforcement , but what happens when an autonomous remediation breaks production is undocumented.
• Graph refresh latency: how stale the knowledge graph can be at query time, and what that does to answer quality under load.
• Pricing: neither service has disclosed any, unlike AgentCore's published per-1,000-event rates .

The takeaway: build on the GA primitives you can price and audit today, and put Context and Continuum on a watch list — not a deployment plan — until AWS publishes the benchmarks, dates, and SLAs that turn vendor framing into something you can verify.

Frequently asked questions

How is AWS Context different from building a RAG pipeline?

A hand-built RAG pipeline puts the engineering on you: chunking documents, generating embeddings, tuning a retrieval engine, and bolting governance on as a separate layer. AWS Context inverts that. It auto-ingests heterogeneous org sources — databases, CRM, documents, email, Slack — infers the relationships between them into a knowledge graph, and applies business rules and access controls at ingestion so an agent only ever reaches governed data . The trade-off is the usual managed-vs-DIY one: Context buys you no retrieval-pipeline code at the cost of control over chunking, ranking, and embedding choices. One practical caveat — Context is described as "coming soon" with no general-availability date , while a RAG stack is something you can ship today.

What does Continuum's exploit validation actually do?

AWS Continuum claims to confirm a vulnerability is real before it alerts you. Rather than ranking findings by an abstract CVSS-style score, it attempts to replicate attack conditions in an isolated, sandboxed environment to prove exploitability, then surfaces only the issues it could actually demonstrate and recommends a specific fix — a network-config change, a permission adjustment, or a code patch . In principle that cuts the false-positive noise that floods CVSS-scored scanners. The important qualifier: this is a vendor-stated capability. As of June 2026 there are no independent benchmarks measuring how well the sandboxed replication actually reduces false positives , so treat the noise-reduction figure as a claim to verify, not a proven result.

Is AWS Context a replacement for AgentCore Memory?

No — they solve different problems and are meant to work together. AgentCore Memory addresses agent statelessness: short-term memory captures turn-by-turn interactions within a single session, and long-term memory extracts cross-session facts, preferences, and summaries, scoped per agent instance by actor ID, session ID, and namespace . AWS Context operates one level out: it maps organization-wide data relationships across systems and exposes them through agentic search . Memory is what an agent remembers about its own conversations; Context is what the agent can reach across the business. You would plausibly use both — Memory for continuity within an agent, Context for governed access to org data outside it.

When can I actually start using AWS Context or Continuum?

Not yet, for either. AWS Context is labeled "coming soon" with no GA date, and AWS Continuum launched in a gated preview limited to select pilot customers as of June 2026 . Neither has disclosed pricing or regional availability . If you want something you can deploy and budget for now, the underlying AgentCore primitives — Memory, Identity, and Gateway — went generally available on October 13, 2025 across nine AWS regions with documented consumption pricing, such as $0.25 per 1,000 short-term memory events and $0.010 per 1,000 Identity token requests .

Does Continuum replace vulnerability scanners like Snyk or Semgrep?

It's positioned above them, not necessarily as a drop-in replacement. Continuum is framed as a full vulnerability-lifecycle platform: continuous discovery, prioritization by organizational context — business priorities, system dependencies, risk profiles — rather than CVSS severity, exploitability validation, and targeted remediation . The related AWS Security Agent, which now integrates with Continuum, adds STRIDE-framework threat modeling, pull-request scanning, and IDE integrations — features that overlap with what scanners like Snyk and Semgrep cover. Whether Continuum integrates with existing tooling or is meant to displace it isn't clear from current documentation, so don't assume you can retire your scanners on the strength of the announcement.