AGNTCon + MCPCon Japan 2026

Most MCP servers in production today are stateful- each client session is pinned to one server instance.

That works on a single node. Add a load balancer and scale horizontally, and sessions start breaking: Kubernetes routes a request to the wrong pod, a Fargate deployment rolls and drops active connections, and NGINX or AWS ALB need special configuration just to keep the server reachable.

The 2026 spec release candidate, locked May 21, fixes this at the transport layer through three SEPs.
- SEP-1442 removes the mandatory init handshake so negotiation folds into the first request.
- SEP-2322 makes elicitation stateless.
- SEP-2243 mirrors routing data into HTTP headers so load balancers can route without parsing the payload.

This session covers what each SEP changes, what breaks in the server you run today, and what to refactor before the spec ships. I'll also show how we externalize session state at Mem0, so a stateless server keeps the memory and context a real agent needs.

You'll leave with a migration checklist and an architecture for stateless-first MCP.

Authorization in MCP has been through a number of revisions in the past year. Some major (remember when the authorization server and resource server were expected to be the same?) and some minor. As the specification has stabilized, it can be difficult to know: Am I doing it right?

In this talk we'll briefly recap where MCP Auth came from and where it is now, and then we'll dig into Auth best practices based on evolving discussions and connecting Claude.ai to loads of MCP servers in practice.

We'll cover things like: client registration, progressive authz with challenges, and enterprise managed auth to leverage existing SSO connections.

We'll also explore the latest extensions in development and how to put them together into a cohesive solution for human-in-the-loop but also agentic and on-behalf-of flows.

Lastly, we'll cover how to leverage MCP's conformance testing suite to see how closely you're following best practices, using either client, server or authorization server test suites.

The MCP 2026-07-28 release candidate introduces a major shift in how agents connect, authenticate and manage state. With a stateless protocol core, first-class extensions and hardened authorization, the new spec improves scalability and interoperability, but it also changes the security model in ways that many builders may not fully anticipate. In this talk, I will examine the release candidate through a defender’s lens and highlight the practical risks that emerge when session state disappears, trust boundaries move and extension-based flexibility expands the attack surface. I will discuss failure modes such as broken state assumptions, capability confusion, unsafe cross-client behavior, and authorization mistakes in real deployments. The session will also cover concrete hardening patterns for secure MCP adoption, including least-privilege tool design, explicit state handling, authorization scoping, telemetry and rollout validation. Attendees will leave with a practical checklist for evaluating stateless MCP systems and defending agent runtimes in production.

The first wave of MCP adoption was defined by abundance. Every API endpoint became a tool, every workflow became a collection of tool calls, and many servers exposed hundreds of operations directly to agents. It worked, but at a cost: bloated context windows, slower tool selection, and increasingly unreliable agent behaviour.

But then Code Mode appeared!

With approaches Code Mode agents can search an API surface, generate code, and interact with services directly. If models can consume entire APIs and write code to acomplish a task, does tool design still matter?

In this talk, we'll compare three approaches to agent tooling: curated workflow-oriented tools, tool discovery and search, and Code Mode's search-and-execute model. Using real-world examples, benchmarks, and evals, we'll explore the trade-offs in reliability, latency, token usage, and task success.

Attendees will leave with a practical framework for deciding when to consolidate tools, when to expose APIs, and whether the future of MCP is better tools or fewer tools altogether.

AI agent discussions often focus on coding or MCP. My starting point is different. I use coding agents such as Claude Code and Codex as assistants for work beyond development. Instead of automating isolated tasks, I keep them beside me as a secretary and knowledge platform for routine operations, speaking requests, internal coordination, slide preparation, and customer-facing project delivery.

That daily use reveals agent-worthy problems. With Markdown, Git, Google Workspace, and MCP in the loop, work becomes context an agent can read, improve, and hand back. I then turn those problems into agents I build, deploy, review, and operate myself.

I will cover Vibe Presales, my term for turning a customer's concerns, constraints, and reactions in a presales conversation into a working demo while the context is fresh. I will also share lessons from a PowerPoint-building agent, including design, deployment, review, and output quality for real slide and proposal work.

These lessons become OSS code, articles, books, and hands-on material. Attendees leave with a loop for living with agents at work, building reliable systems, and sharing reusable lessons.

What happens when an AI agent has to pay for its tools? Today, nobody knows. Open-source MCP servers run for free, and their maintainers quietly absorb the cost. The x402 protocol changes the model: a server can charge a small payment for each tool call, with no accounts or API keys needed. The plumbing works. The open question is how agents behave once tools have a price.

We put it to the test. We ran a paid MCP server for several weeks and watched agents act as customers. We changed prices to find the point where agents stop calling a tool. We offered the same tool free and paid, side by side, to see whether agents compare prices or just call the first match. We let spending budgets run out mid-task to see what agents do when money gets tight. And we compared all of this across four agent clients: Google ADK, LangGraph, the OpenAI Agents SDK, and Claude Code.

The result is practical guidance for maintainers: what to charge, where the payment flow breaks, which framework behaviors to expect, and whether per-call payments can realistically fund an open-source MCP server.

Every team building agentic systems hits the same wall: the gap between a demo and a system you'd trust in production. Most assume it's an engineering problem. It isn't. It's a governance problem and governance in a multi-agent system isn't a policy document. It's the full data path.

We demonstrate a production-style multi-agent workflow where customer feedback flows through agents, MCP tools, GitHub integrations, and multiple LLM providers before triggering automated actions.

We show how cloud-native primitives govern every interaction: OpenTelemetry for distributed tracing across agent hops, OPA for declarative policy enforcement, API gateways for prompt injection protection and model routing, and Kubernetes for workload isolation.

The hardest part of running agents in production isn't the AI. It's the same problems Kubernetes solved for microservices, observability, traffic management, policy, workload isolation applied to a new class of workload the ecosystem is still learning to instrument.

A production issue spans multiple cloud environments. Everything looks fine in isolation, but the system behaves unexpectedly end-to-end. Reconstructing what is actually deployed requires stitching together cloud consoles, infrastructure definitions, and internal tooling.

AI agents could help with this kind of problem, but they need better context. Infrastructure is a key part of that context gap. Cloud resources, environments, configurations, and policies are essential for reasoning and decision-making, yet this information is fragmented across infrastructure-as-code, cloud providers, and internal systems.

This talk explores why a developer platform was built: to unify infrastructure management, standardize how teams provision and manage cloud resources, and provide a consistent abstraction across providers, accounts, and environments. The platform then evolves into a unified source of infrastructure context, aggregating metadata into a coherent infrastructure blueprint. By exposing this through an MCP server, it allows AI agents to understand the full infrastructure landscape, improving reasoning, troubleshooting, and the quality of assistance in engineering workflows.

MCP grants AI agents access to file systems, Git, cloud, and SaaS. Yet permission models — IAM, OAuth scopes, PATs — were built for humans and fall short for AI.

The issue isn’t granularity. Existing permissions assume “human rationality” as a boundary: write access doesn’t mean a human wipes a repo; CI write access doesn’t mean a human exfiltrates secrets. Permissions stay broad because human judgment fills the gap. AI lacks this buffer — through prompt injection or edge cases, it acts destructively where a human would stop. Per-call approval collapses under fatigue.

As an SRE on strong production credentials, my question wasn’t “how to restrict AI” but “how to maximize safe delegation.”

I propose Intent as Code: coding what was left to human rationality. Three OSS tools:
safe-push rejects pushes touching .github/ or others’ commits, preventing CI hijacking
safe-gh wraps gh CLI with conditions like “only own issues” or “only approved PRs to develop” — expressing intent PATs can’t
safe-webfetch uses Claude Code Hooks to auto-allow learned-safe URLs, cutting fatigue decisions

Attendees leave understanding why permissions fall short for AI, with patterns to apply.

The MCP spec is clear about how one client and one server talk to each other. It says much less about what happens when the client is itself a distributed system, serving millions of people across thousands of third-party MCP remote servers.

At Anthropic, we run a proxy between our products and a large, growing set of remote servers. At that scale, we started running into problems the spec doesn't answer.

This talk is about three of them:

- Authentication: How do we make authentication work across servers that all implement it a little differently? How do we keep people connected when connections drop and credentials expire, without making them sign in again?

- Caching: How do we avoid hammering the MCP remote servers, and which caching strategies make that possible?

- Monitoring: How do we monitor a system where the servers vary widely, from stable production ones to unstable ones still in development? When something breaks, how do we tell whether the fault is ours or the server's?

AI agents have long been capable of interacting with the web, relying on brittle DOM scrapers and heavy browser automation has kept these workflows slow and prone to failure. We will explore how the WebMCP shifts agentic web interaction from merely functional to highly performant and efficient by providing a standardized, machine-readable layer for context sharing and action execution. WebMCP eliminates the friction and overhead of legacy automation techniques.