AGNTCon + MCPCon Japan 2026

Automating scientific research is one of the most important uses of AI agents, and as agents grow more autonomous, it is quickly becoming realistic. We can already let an agent run research that takes hours or even days.
The main challenge is not whether the agent finishes, but how much we can trust the results it reports. A result that looks successful may come from a misunderstood setup or a manipulated metric. Checking it by hand is hard, and asking another agent to check it only moves the problem one step further.
Being too strict is also risky. A good idea does not always give results quickly, and it is easy to find reasons to call a result a failure. A system that rejects too easily throws away promising research, while ideas that lead nowhere should be stopped early. Balancing proper rejection and reliable acceptance is the hardest part of automated research.
Based on my experience running agentic research-automation systems, I will explain how these problems appear in long-running tasks and the approaches we are developing to keep research reliable.
You will leave with a practical framework for trusting and using long-running autonomous agents in research and beyond.

___________________________
Presentation Language: Japanese

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.

___________________________
Presentation Language: English

___________________________
Presentation Language: English
Captioning will be available for attendees in 50+ languages through Wordly. See instructions in each room to utilize captioning.

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.

___________________________
Presentation Language: English

Captioning will be available for attendees in 50+ languages through Wordly. See instructions in each room to utilize captioning.

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.


___________________________
Presentation Language: English
Captioning will be available for attendees in 50+ languages through Wordly. See instructions in each room to utilize captioning.

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 built a paid MCP server on Cloud and ran it end to end, live, settling real payments on a public testnet. We put the agent behind an identity provider and a policy gateway, to see what a paid tool call has to carry before anyone would run one in production. We gave the same work to two competing vendors to see who really decides which one gets bought. And we varied the system prompt, to see how much of a model's spending behaviour is a property of its instructions rather than of the request.

The result is practical guidance for maintainers: how to price a call, where the payment flow breaks, which model behaviours to expect, and whether per-call payments can realistically fund an open-source MCP server.

___________________________
Presentation Language: English

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.


___________________________
Presentation Language: English

As multi-agent systems move to production, managing persistent state and data lineage across independent tools is a critical engineering bottleneck. This session explores the architectural gaps in current agent workflows and introduces an open-source approach to building structured, tiered datastores using the Model Context Protocol (MCP).

We will present the concept of an "agent-native data layer" and the "datapack" framework—designed to decouple and layer data specifically for multi-agent environments. Attendees will learn how an open-source MCP server can act as a unified abstraction layer to securely bridge public and proprietary data. You will walk away with actionable design patterns to ensure independent tools seamlessly retain state and context without vendor lock-in.

___________________________
Presentation Language: English

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.

___________________________
Presentation Language: Japanese

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?

___________________________
Presentation Language: English

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.

___________________________
Presentation Language: English