What AWS Summit New York 2026 taught me about the infrastructure, identity, context, and governance behind production AI.
On June 17, I walked into the Jacob K. Javits Convention Center expecting the usual conference rhythm: a keynote, a crowded expo floor, and more sessions than anyone could attend. With more than 200 learning experiences, choosing a route already felt like an architecture decision.
I followed one thread: how do agents move from an impressive demo to a system a company can trust?
That question took me from Swami Sivasubramanian’s keynote to sessions on Amazon Bedrock AgentCore Runtime and Gateway, then Anthropic’s view of enterprise agents. Afterward, I studied the data and security announcements I missed.
The day left one clear idea: the agent is becoming the smallest part of the agent platform.
What was AWS really announcing?
AWS VP of Agentic AI, Swami Sivasubramanian, delivered the keynote with Southwest Airlines CIO Lauren Woods. AWS reported that tasks completed through Amazon Bedrock AgentCore had grown 15× in six months. Southwest, meanwhile, is working toward a cloud-based, agent-enabled architecture by 2028, with more than 2,700 developers already using Kiro.
The keynote moved through three connected loops: agents for work via Amazon Quick, agents for security via AWS Continuum, and agents for building via Kiro, DevOps Agent, and AWS Transform. Amazon Quick also gained autonomous background agents, a sign that AWS expects agents to run continuously in the background of work rather than wait for a prompt. The underlying idea was an AI-driven development lifecycle spanning inception, construction, and operations. It was not a coding assistant isolated inside an IDE.
The centerpiece was the general availability of the Amazon Bedrock AgentCore harness. Instead of hand-writing an orchestration loop, developers describe a model, tools, skills, and instructions in configuration. The harness provides the surrounding machinery: tool execution, memory, context handling, and error recovery.
Teams building agents have repeatedly implemented the same supporting components: session state, retries, tool schemas, context trimming, credential exchange, sandboxing, tracing, and evaluation. None is the business reason for the agent, but any one can stop it from reaching production.
AWS is turning that scaffolding into the platform.
Why does context matter more than another model?
The keynote’s most ambitious announcement was AWS Context, described as a forthcoming governed knowledge graph spanning structured and unstructured organizational data. The promise is not simply to retrieve documents. It is to learn which sources, relationships, and business rules produce useful answers, then make that understanding available across agents.
That direction makes sense. In production, the model is rarely the only source of failure. An agent fails because it found an old policy, missed the relationship between a customer and an account, used a tool with the wrong permissions, or lost the important part of a long conversation.
AWS also announced the general availability of Amazon Bedrock Managed Knowledge Base, which brings native connectors, Smart Parsing, and an agentic retriever to managed RAG workflows. Web Search on AgentCore adds current, cited web information while keeping queries inside the customer’s secured AWS environment.
Put together, the message was hard to miss: model choice still matters, but usable context is becoming the real competitive layer.
What did the AgentCore sessions reveal that the keynote did not?
The breakout sessions were the most valuable part of my day because they exposed the constraints behind the product story.
One slide asked, “How do I control the size of the agent execution environment?” The answer was blunt: “You don’t.”
That answer points to a practical design pattern: keep the agent loop thin. Let it reason, route, and coordinate; send heavy data processing to Lambda, AWS Batch, or another purpose-built compute service through tool calls. A monolithic agent that performs orchestration and expensive computation in the same runtime becomes difficult to scale, secure, and debug.
The session also described strong isolation around execution. Agent sessions run in dedicated Firecracker microVMs, extending the isolation model behind Lambda to code and shell execution initiated by agents.
My biggest takeaway was simple: do not size an agent like an application server. Design it like a coordinator.
Why was AgentCore Gateway the best session of the day?
The AgentCore Gateway deep dive connected the architecture end to end.
Gateway presents a single Model Context Protocol (MCP) endpoint to an agent while composing very different targets behind it: Lambda functions, OpenAPI services, Smithy models, and other MCP servers. It validates tokens, manages credentials, and helps select tools semantically instead of forcing a model to absorb hundreds of tool definitions at once.
The credential flow was the part I kept thinking about afterward. A user’s platform token reaches Gateway, is exchanged for the credential required by a specific downstream tool, and the original secret does not have to pass through the agent. The agent can act on the user’s behalf without becoming a container for the user’s credentials.
The session also clarified a distinction that teams can easily blur:
- Policies are declarative governance. A rule such as “refunds above $500 require approval” should be enforced outside the model.
- Interceptors are imperative integration logic. Token exchange, header injection, logging, or PII redaction may require code before or after a tool call.
Governance and integration are related, but they are not the same problem. Treating them as separate control planes produces a cleaner system.
Can an agent act on behalf of a user without becoming the user?
A separate Ping Identity and AWS session pushed the identity question further. Its reference architecture split the system into a conversational Request Agent and a hardened Action Agent. The Request Agent handles interaction but remains unprivileged. When work must be performed, it delegates to the Action Agent, which operates behind policy and reaches PingOne, AWS, and other MCP servers through controlled interfaces.
That separation solves a problem that many agent demos hide. A conversational model may need to understand a user’s request, but it does not automatically need the authority to execute every possible action. If the same component holds the conversation, the access token, and the execution privileges, one prompt-injection failure can become an authorization failure.
The safer pattern is least privilege for agents: give the conversational layer enough context to decide what should happen, then let a policy-controlled component decide what is actually allowed. In the session’s words, keep conversational AI unprivileged and put execution behind a policy-driven Action Agent.
The credential-exchange walkthrough made the pattern concrete. The downstream MCP tool receives a JWT, exchanges it for the integrated service’s access token, and then acts on behalf of the user. The platform token does not cross into the external service, and the model never needs to see the long-lived credential.
This was one of the most practical lessons of the Summit: agents need first-class identities, auditable delegation, and policy boundaries, not a shared service account with a large permission set.
What did Anthropic add to the picture?
The Anthropic material made the enterprise distribution strategy concrete. There are now three AWS-billed paths to Claude: Claude Enterprise through AWS Marketplace for business users, Claude Platform on AWS for developers, and Claude on Amazon Bedrock for workloads that need AWS-operated governance and data locality.
That matters because enterprise AI adoption is not one workload. A company may want a workforce chat product, a developer platform with first-party Anthropic features, and a regulated application running through Bedrock controls at the same time.
Anthropic’s sessions also emphasized context engineering: choosing the right prompt altitude, retrieving information just in time, compacting long interactions, using structured memory, and delegating to sub-agents. Those ideas reinforced what I had heard all day. Better agents will not come only from larger models. They will come from better systems around the models.
What did I miss, and what was still worth studying?
No honest Summit recap should pretend one person attended every important session. While I followed the agent-runtime and Anthropic track, two parallel threads deserved a closer look afterward.
The first was data. Amazon S3 annotations can attach up to 1 GB of rich, mutable, queryable context directly to an object. For a data engineer, that changes a familiar design decision: metadata no longer has to live in a sidecar database synchronized through custom jobs. The benefit is discoverability; the new responsibility is governing who can change the context that agents may use to interpret the object. Amazon S3 Vectors query charges also dropped by up to 80 percent for large indexes, applied automatically, which turns the managed-versus-self-managed retrieval decision into a cost-modelling exercise as much as an architecture one.
The second was security. AWS Continuum entered gated preview with a continuous code-vulnerability workflow: discover, prioritize, validate, and remediate. AWS Security Agent, now part of Continuum, adds STRIDE-based threat modeling, pull-request scanning, and integrations with Kiro, Claude Code, and MCP.
That is the correct direction. If agents can act at machine speed, security cannot remain a quarterly review attached to the end of development.
So what should teams building agents do next?
Watching AWS make these components managed did not make our earlier work feel wasted. It clarified where engineering effort should move.
Do not begin with “Where can we add an agent?” Begin with a bounded workflow, an accountable owner, and a measurable definition of success. Keep the orchestration loop small. Put authorization and policy outside the model. Treat retrieval quality as a testable system, not a demo. Evaluate failure paths before optimizing the happy path. And measure the entire request, including tool calls and data access, not only model tokens.
The question in 2025 was, “Can we build an agent?”
The question after AWS Summit New York 2026 is, “Which workflows deserve one, and can we operate it responsibly?”
That is a harder question. It is also where the interesting work begins.
Questions people will ask
Should we replace a hand-built agent with AgentCore harness?
Not automatically. If your custom code mostly manages sessions, retries, tool calls, and context, map those pieces to the managed services and migrate incrementally. If your orchestration loop contains genuine domain logic, benchmark carefully before replacing it.
Does Managed Knowledge Base replace every custom RAG pipeline?
No. It raises the baseline for general enterprise retrieval. Specialized ranking, hybrid search, or strict relevance targets still need comparative evaluation.
What was my favorite session?
The AgentCore Gateway deep dive. It moved past the “agent as chatbot” framing and showed the identity, credential, policy, and routing machinery required for an agent to act safely.
What was the best part that was not on a slide?
Working at a largely remote company, the real highlight was meeting colleagues in person for the first time, including our CEO, Traey Hatch. Conference stages show the product vision; hallway conversations reveal what is actually working in production. Worth the train ride for that alone.