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

MCP makes it easier for AI agents to connect to enterprise systems, but moving from experimentation to production raises a deeper question: is controlling what an agent can access enough? An agent may have permission to update customer data, but that doesn't mean every authorized action should be executed in the same way.

This talk introduces the distinction between Access Control — what an agent is allowed to do — and Execution Control — how an authorized request should actually be carried out. We'll explore how mechanisms such as business rules, deterministic logic, and auditability, among others, can work together behind MCP tools to shape how execution happens in the enterprise.

The goal is to provide a practical architectural lens for teams taking MCP beyond adoption and into production: enterprise trust requires controlling not only what agents can access, but how their actions are executed.

___________________________
Presentation Language: Japanese

As AI agents increasingly invoke tools, access enterprise data, and collaborate, a new architectural challenge emerges: Where should trust boundaries be defined, and where should governance and security controls be enforced?

To explore this, we conducted a technical PoC introducing a shared control layer across agent-to-agent communications and tool execution pathways. Rather than presenting an ideal architecture, this session focuses on practical challenges and lessons learned during implementation.

Key topics include:
- Defining the "Agent": How to define what constitutes an agent in an ecosystem and where to establish trust boundaries for validation, monitoring, and control
- Architectural Insights: Redesign considerations and insights that emerged through prototype development and PoC activities.
- Performance Trade-offs: Balancing stronger security and governance with the low-latency requirements needed for real-world deployment.

We will share practical takeaways on designing trust boundaries and navigating trade-offs among security, governance, and operational performance.

___________________________
Presentation Language: Japanese

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

A web service exposes /health; a phone line exposes nothing. The telephone is the oldest telecommunication tool still in production — and our LLM voice agents answer customer calls over it, with no way to know whether they are answering, hearing, and behaving correctly right now.

So we gave a frontier model a telephone.

Our MCP server gives any LLM a phone: dial PSTN numbers, speak via TTS, and read the other side via silence-detected transcripts. A frontier model becomes the caller, phoning our production voice agents in an agent-calls-agent loop — one mechanism covering the whole testing spectrum: ping-style health checks, deep evaluation via scripted and adversarial conversations, and load testing with concurrent caller fleets.

We cover the MCP tool design for a domain the spec wasn't written for — tools that block for tens of seconds, turn-taking over live audio, per-call session state — where the spec fought us and what we would feed back, plus what broke: timeout cascades and evaluations that flap.

We are open-sourcing the server. You'll leave knowing how to connect your own agent to the PSTN — and how to ping, probe, and load-test anything that answers a phone.

___________________________
Presentation Language: Japanese