AWS Summit NY 2026: AgentCore, Continuum and Context

AWS Summit New York 2026, held June 17 at the Javits Center, was the moment Amazon Web Services stopped selling AI building blocks and started shipping end-to-end agentic infrastructure. The keynote, led by Swami Sivasubramanian, AWS’s VP of Agentic AI, threaded a single argument through every announcement: builders should no longer assemble agent scaffolding by hand.

Three product families carried that thesis. AgentCore became a free managed harness for running production agents. AWS Continuum arrived as an AI-native security platform with a deliberate trust model. And AWS Context was announced as a coming-soon knowledge graph that any agent in an organization can query at runtime. Underneath all of them sits the same design question: how do you let an agent do more without writing it a blank check?

This guide covers what actually shipped versus what was merely announced, the autonomy-escalation pattern that ties the portfolio together, how AWS Context compares to the context-layer products from Microsoft, Google, and Salesforce, and what builders and engineering teams should do about it. Every figure below is sourced to AWS’s own blogs or named third-party summit coverage; vendor-stated claims are labelled as such.

For two years the cloud-vendor agent pitch was a parts catalog: models here, vector stores there, an orchestration framework you wire up yourself, and governance bolted on afterward. The New York summit was AWS arguing that phase is over. Matt Wood, AWS’s Chief AI and Technology Officer, framed the obstacle plainly during the keynote, putting trust rather than raw capability at the center of why enterprises stall on agents.

That framing matters because it reorders the roadmap. If trust is the bottleneck, then the most valuable thing a cloud provider can ship is not a smarter model but a way to grant autonomy incrementally and prove the limits hold. Almost every announcement at the summit — the free harness, Continuum’s staged enforcement, deterministic spend caps, granular autonomy levels in Amazon Quick — is AWS operationalizing one answer to that single question.

Wood paired that with an economic observation: while the cost of a token at the frontier keeps rising, the cost normalized for a fixed point of intelligence keeps falling year over year. Read together, the two ideas are the business case for the whole portfolio — intelligence is getting cheaper per unit, so the constraint shifts to whether organizations trust agents enough to actually deploy them at scale. That is what AWS spent the summit trying to fix. This positions AgentCore within the same broader pattern as an enterprise agent infrastructure reference architecture rather than a standalone tool.

The headline builder announcement was the Amazon Bedrock AgentCore Managed Harness reaching general availability. The pitch is blunt: a production-grade agent in three API calls with zero orchestration code. Each harness session runs in its own microVM with filesystem and shell access, and persistent filesystem state lets an agent suspend mid-task and resume exactly where it stopped — the kind of durable execution most teams previously hand-built.

The commercial structure is the part worth dwelling on. There is no additional charge for the harness, the AgentCore CLI, or the coding skills; customers pay only for the underlying AWS resources consumed. The harness is available across 14 AWS regions via the CLI, with the Managed Harness in preview across four regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt), and Asia Pacific (Sydney).

One forward-looking piece, AgentCore Payments, is in preview. Built with Coinbase and Stripe, it is designed to let agents pay for APIs, MCP servers, web content, and other agents via the x402 protocol, with the Coinbase x402 Bazaar MCP server exposing more than 10,000 payable endpoints. Because it is preview-only, treat it as a glimpse of agent commerce rather than a system actively transacting in production — though the design choice underneath it is telling, and it maps directly onto the emerging agent marketplace ecosystem.

No single AWS slide laid it out, but the announcements collectively define a trust ladder — a map of how each product grants more autonomy and what holds the limit. The table below makes it explicit. Note the recurring pattern in the right-hand columns: the control that enforces an autonomy limit is almost always deterministic infrastructure, not the model deciding to behave.

The throughline is the original analysis worth taking away: AWS is not asking customers to trust a model. It is asking them to trust infrastructure that constrains the model — microVM isolation, formal verification, gateway-layer guardrails outside the agent’s visibility, and spend caps enforced below the reasoning layer. Bedrock Guardrails sit in the gateway specifically so that a prompt-injection attack against the agent cannot circumvent governance. That is a meaningfully different trust story than “the model was trained to refuse.”

AWS Continuum was announced as an AI-native security platform in gated preview. It operates across four continuous phases — Discovery, Prioritization, Validation, and Mitigation/Remediation — and the validation phase is its genuinely novel move. Rather than scanning and suggesting, Continuum constructs a working exploit in a sandboxed environment to prove a vulnerability is real before proposing a fix. Concrete reproducible proof, not a probabilistic severity score.

The governance design is the second differentiator. Continuum runs in learn mode by default — supervised, human-in-the-loop — and organizations advance category-by-category to enforce mode for automated remediation only as they build confidence. It is, in effect, the first enterprise security agent with a deterministic autonomy escalation path baked into the product, which is exactly why Continuum’s staged model maps so cleanly onto a staged framework for deploying agents into enterprise workflows.

Continuum is model-agnostic and was built using data and code samples drawn from AWS and Amazon. It integrates with Git platforms for pull-request code scanning and supports IDE access via Kiro Power, a Claude Code plugin, and MCP. A separate preview, Continuum Threat Modeling, uses the STRIDE framework to auto-generate threat models from design documents or application source code. Worth keeping straight: Continuum for code vulnerabilities is the GA-ready piece, while code scanning and threat modeling are separate previews — the platform as a whole is not generally available.

On why AWS moved when it did, Chet Kapoor, AWS’s VP of security services and observability, attributed the acceleration to Anthropic ’s Claude Mythos model, describing its ability to find and chain software vulnerabilities faster than any human team as a catalyst for the Continuum timeline. He called it a turning point that significantly advanced AWS’s plans. Two cautions: that is a vendor-stated motivation rather than an independently audited claim, and Mythos is offered to select organizations — not a publicly available model builders can call directly.

AWS Context was announced as a coming-soon service that automatically builds a knowledge graph from an organization’s existing data. It reads databases, documents, Slack history, and email, infers how everything connects, and makes that map available to every agent in the organization at runtime. Mai-Lan Tomsen Bukovec, an AWS Technology Vice President, framed it as the data lake for AI agents — the shared substrate agents query rather than each rediscovering the schema on their own.

The architecture has two features that separate it from a generic knowledge base. First, governance is identity-aware: each query inherits the calling user’s IAM and Lake Formation permissions, so an agent acting for one user cannot see what that user cannot. Second, metadata is stored in Apache Iceberg format in Amazon S3 Tables, queryable through Amazon Athena and Amazon Redshift — open table format, not a proprietary index. AWS says Context is built on the same technology that powers Amazon Quick, which processes millions of requests daily in production.

Most coverage treats AWS Context in isolation, which misses the strategic shape of it. AWS is the fourth major cloud or AI vendor to ship a context-layer product, after Microsoft’s GraphRAG in Azure AI Search, Google’s Vertex Grounding, and Salesforce’s Data Cloud semantic layer. The table below frames the four head-to-head. The distinctive AWS claim sits in the auto-learning column — and it is exactly the claim still awaiting independent verification.

The architectural distinction AWS is selling is real but unproven: the other three build their graph from a pipeline you configure or a model you maintain, while Context claims to learn graph topology from how agents actually query. If that holds up, it is a genuinely different operating model — less ETL, more observation. If it does not, Context is a well-governed entrant in a category that already has three shipping products. The honest read today, given that Context is coming-soon and the differentiator is vendor-stated, is to evaluate it on availability rather than on the marketing claim.

Kiro for iOS, announced in gated preview, is a true native app rather than a web wrapper, with three interaction modes: chat, spec (continuing a specification workflow), and autonomy (delegating a full task). The signals story is the architecture underneath: compute runs in the AWS cloud, so a session keeps running after the phone screen goes dark. It reads less like a code editor on a phone and more like a remote control for long-running agents. For the full desktop story, our guide to Kiro, AWS’s agentic IDE covers the spec-driven workflow the iOS companion extends.

That untethering reframes what an agentic IDE is. If a task can run for hours unattended while you walk away from the desk, the IDE is infrastructure, not an editor — and supervision becomes the primary human job. AWS leaned into the case-study angle here: it cited Southwest Airlines deploying Kiro to more than 2,700 developers as part of a transition to a cloud-based, AI-enabled architecture, a customer figure that is vendor-stated.

A naming caution that trips up most coverage: do not conflate Amazon Quick with the developer tooling. Amazon Quick is the enterprise productivity assistant — it added 16 new built-in integrations (including Adobe, Moody’s, and Snowflake), a redesigned activity feed, and no-code autonomous agents. Kiro is the developer IDE. They are separate products with separate autonomy models, and Context is built on the same technology that powers Quick, not Kiro.

Looking forward, the summit reads as AWS standardizing the agent stack the way it standardized container orchestration: own the managed layer, give the tooling away, and monetize the runtime. For teams, that turns a build-versus-buy decision that was open six months ago into a more nuanced one. The decision tree below is how we would scope it today.

For most agencies and engineering teams, the practical move is to treat the GA pieces and the preview pieces very differently. Build pilots on the free AgentCore Harness today; request gated access to Continuum and evaluate its learn mode against a real codebase; and hold AWS Context as a roadmap item, not a dependency. If you are weighing how this fits a broader agentic strategy, that comparative scoping is exactly where our AI and digital transformation engagements start, and where our CRM automation work grounds agent pilots in a workflow that pays for itself.