AWS Summit NY 2026: AI Agents Just Became a Managed Product

If you've built an AI agent in the last two years, you've written the same plumbing everyone else has: the loop that calls the model, parses a tool request, runs the tool, feeds the result back, handles the retry, manages the context window. It's not hard, exactly. It's just yours, and you maintain it forever.

At AWS Summit New York 2026 this week, AWS made a clear bet that you shouldn't have to. A run of announcements — led by Bedrock AgentCore Harness going GA — turned the parts of an agent you used to hand-assemble into managed boxes you configure. And the most interesting one wasn't the flashiest. It was a knowledge-graph service that quietly says vector search isn't enough.

Two threads ran through the whole show, and they're really one thesis: the model isn't the bottleneck anymore — grounding is — and AWS wants to own every layer of it.

Thread one: the agent loop is now boilerplate

AgentCore Harness (GA) is the headline. The pitch is that you deploy a production agent from configuration, not code: declare the model, the tools, the skills, and the instructions, and the orchestration runs for you. No hand-rolled loop to write or babysit.

It doesn't ship alone. Stacked around it:

• Web Search on AgentCore — a fully managed search tool so your agent can ground answers in current, cited web results, with zero data egress out of your AWS environment.
• Bedrock Managed Knowledge Base — enterprise RAG as a service: native data connectors, "Smart Parsing," and an Agentic Retriever wired into the AgentCore Gateway.

Put together, the message is unmistakable: the loop, the retrieval, the web grounding — the parts you used to assemble by hand — are becoming managed primitives.

I've seen this movie. There was a time everyone hand-wrote their HTTP server, their session handling, their templating. Then frameworks arrived, absorbed the boilerplate, and the conversation moved up a level — you stopped thinking about sockets and started thinking about features. DIY agent orchestration is hitting that exact inflection. And the timing isn't a coincidence: Microsoft put agents in Windows at Build, Apple put them in Xcode at WWDC, and now AWS is turning the agent runtime into a managed service. The platform vendors have collectively decided agents are a primitive.

Two things I genuinely like about the config-first framing:

1. Web grounding with zero egress. "Let the agent search the web" usually means shipping your queries — and context — out to some third party. A managed search that stays inside your environment and returns cited results is the difference between a demo and something a cautious team will actually run.
2. Skills as configuration. I already package reusable instructions as skills in the tools I use daily. Treating skills as a first-class config knob on a managed agent — rather than something you bolt on — is the right altitude.

Thread two: grounding gets a graph, not just embeddings

Here's the announcement that stuck with me, and it's not the loud one. AWS Context (previewed, coming soon) automatically maps your data's relationships into a knowledge graph, then exposes that graph for governed agent access to business rules and domain knowledge.

Why it matters: most "give your agent context" tooling does the same thing under the hood — chunk your documents, embed them, pull back nearest neighbors at query time. It works, and it's also why RAG agents confidently miss things. Embeddings tell you what's similar; a graph tells you what's connected. A vector store retrieves the three chunks most semantically similar to your query. A graph lets you traverse — this order belongs to this customer, who is on this plan, governed by this policy, changed by this ticket. "Which customers are affected by this expired contract" isn't a similarity question. It's a relationship question, and it's exactly what vector search fumbles.

The catch has always been that building the graph is the hard, manual part — someone has to define the entities and edges. AWS Context's pitch is that it builds the graph for you, turning the expensive step into a managed one. (Full disclosure: I spend a lot of my own time turning inputs into graphs, so I'm biased toward this being the right direction.)

The word I don't want to skip is governed. A raw graph an agent can roam freely is a data-exfiltration incident waiting to happen — the agent helpfully traverses an edge it should never have followed and surfaces something it shouldn't. Putting governance — what an agent may traverse, which relationships are off-limits — in the same announcement as the graph, rather than as a later add-on, is the right instinct.

The reflexive worry

Config-driven anything trades control for convenience, and agents are control-heavy by nature. The whole craft of a good agent lives in the loop: when to retry, how to compact context, when to stop, how to verify before claiming "done." My standing question on this blog is exactly that — how much of the loop can you trust versus verify. Hand the loop to a managed harness and you've also handed over the part where most agents quietly fail.

The graph has its own version of this. An auto-built graph with wrong edges is worse than no graph — it grounds the agent in confident nonsense, and now the nonsense is structured. The convenience is real; so is the question of what you can still tune when the system does something dumb at 2am.

What I'm going to try

I haven't built on any of this yet — it's days old, and Context is still a preview — but it's the kind of thing I can poke at from the Mac I already have, pointing at a hosted model rather than standing up anything heavy. Over the coming months, the questions I'll be taking in:

• How far does config-only actually get you on Harness before you hit a wall and need a code escape hatch — and how clean is that hatch?
• Web Search grounding quality. Cited and zero-egress is the promise; how good are the citations when the question is genuinely current?
• Managed Knowledge Base vs. a RAG I'd hand-roll. Does "Smart Parsing" and an Agentic Retriever beat a careful DIY pipeline on messy real documents?
• How good is the auto-built graph in Context? On real multi-hop questions, how much does traversal beat nearest-neighbor — and how granular is the governance (per-node, per-edge, per-relationship-type)?
• Does Context play with the graphs I already build, or is it a closed box?

The bigger picture is worth sitting with. A year ago, building an agent meant writing the orchestration; this week AWS made a credible case that orchestration is becoming a checkbox. And the layer that's left — grounding the agent in the right facts, correctly connected — is the one AWS is racing to own end to end, from managed RAG to web search to a knowledge graph of your own data. I think the thesis is basically right: the frontier models are already good enough for most business tasks, and what makes an agent useful or useless is whether it's standing on the right facts.

Which means the interesting work just moved up a level — from "make the loop work" to "make the agent worth trusting." That second problem is a lot harder, and no config file solves it.

AgentCore Harness and managed web search are GA now; AWS Context is in preview. I'm planning to wire a small agent to this stack against a hosted model over the next couple of months — field report to follow.