AGNTCon + MCPCon Japan 2026

Your agent swarm is running. It's browsing the web, calling APIs, reading files, making decisions, all on behalf of your users and your organisation. But ask yourself: do you know which agent did what? Can you revoke access to just one of them? Can you prove to an auditor that your agents only touched what they were supposed to?

Probably not. Because most agentic deployments treat agents as anonymous processes : no identity, no credentials, no audit trail, no way to fire them when something goes wrong. If a human employee operated this way, you'd call security. For agents, we call it production.

This talk proposes a fundamentally different approach: onboard your agents like employees. Every agent in your swarm deserves a verifiable identity, scoped permissions, a centralised audit trail, and an offboarding process. Drawing from experience securing cloud native and AI infrastructure, this session presents a blueprint for an open source "Okta for agents"! composing Identity Providers, API gateways, and policy engines to bring the same governance we give humans to the systems acting on their behalf.

You hired 1000 people. It's time to learn their names.

AI-powered incident response sounds like the perfect use case for autonomous agents, but giving them unrestricted access to raw alerts and logs can quickly turn automation into hallucination. Whether you're debugging production outages or investigating failed deployments, engineers still spend hours manually correlating signals across disconnected observability tools.

In this talk, we'll break down the anatomy of a reliable agentic incident investigation system and show why structured incident context outperforms raw telemetry, how evidence enrichment improves reasoning, and why bounded context is critical for trustworthy AI agents.

We'll walk through production-ready patterns for building dependable operational agents:
1. Structured evidence gathering from Datadog, New Relic, Splunk, and Prometheus
2. Context engineering through alert correlation and deployment metadata
3. Long-term memory using historical incidents stored in a vector database
4. Human-agent collaboration that validates AI-generated RCAs and continuously improves future investigations.

Thus helping you reduce manual triage, lower MTTR, and build reliable, production-ready AI-driven incident response systems.

Graph-based code intelligence (not GraphRAG) is the infrastructure primitive that AI coding agents need to reason about large codebases without burning tokens. In this session, we'll evaluate various approaches and identify where the field is converging.

Agents fall back to grep because retrieval solutions return a probabilistic approximation of the code at a given point in time. The context goes stale on changes and loses fidelity when going from code to embeddings. By exposing a call graph, based on established compiler theory, to the LLM through a series of functions and tools, the LLM doesn't need to waste tokens because it has access to deterministic, structured, quick access data from which it can get cheap, reliable answers.

Sourcegraph, Meta's Glean, Google's Kythe, GitHub's Stack Graphs, and newer efforts like GitNexus and Aleutian Trace are all building graph based offerings for LLMs. This session provides a deep dive into the problems faced by agents working in large codebases, maps the solution space of graph based coding tools vs more common LLM solutions— RAG, GraphRAG, pure traversal, embeddings — and then shows where each wins or breaks.

Every agent system is two things: the model, which you rent, and the mask - the character - which is yours. The industry keeps upgrading the model and expecting the mask to improve. It doesn't work that way.

I'm a LAMDA-trained actor turned agent engineer. This talk is the actor's toolkit applied to shipped systems. Case one: a comms pipeline in production at a major crypto protocol - the generating model does Stanislavski table-work (super-objective, through-action, lining) before writing a word; a separate director model audits it blind; and voice is scored by a Laban Movement Analysis classifier that grades the human-written corpus and the machine's output on the same instrument. Brand voice becomes a falsifiable measurement. Case two: the home lab - eleven agents built with a Stanislavski character method, orchestrated over MCP, running my actual work.

You'll leave with the model/mask distinction, a character pipeline you can copy, and the failure modes: drift, voice collapse, paint-by-numbers slop.

The AI industry has moved so fast that we are still evaluating probabilistic software using the same deterministic metrics we applied to traditional code. As a Product Analyst working on AI agents at PagerDuty, I saw a critical need for a new observability standard, one that moves beyond clicks to measure true reasoning and reliability. To address this, I’ve developed and open-sourced a specialized framework designed to help teams decide, with data, when to hire, train, or fire an AI agent. In this session, I will walk through the H.I.R.E. Framework methodology and share the technical architecture of an evaluation pipeline that turns qualitative conversational data into structured, actionable product insights. I will share the open-source repository containing these metric definitions and templates, providing resources for the community to move past agent-washing and toward building verifiable, trustworthy agentic systems.

"Every MCP server, skill, and plugin in your coding agent is code or instructions you never really reviewed, running with your access to your database, your repos, and your keys. Three different ways in, and almost nobody is watching any of them."

Most of the agent security conversation is about prompt injection. Meanwhile there are three underserved vectors sitting right inside the tools you use every day:

- **MCP servers** run with the same access you have. One can look clean when you approve it and change its behavior later, or pull in a compromised dependency on the next run.
- **Skills and instruction files** (`SKILL.md`, `AGENTS.md`, `CLAUDE.md`, rules files) are just text. Nothing to install, nothing to flag. They quietly reshape what your agent does, and hidden instructions, zero-width characters, and pipe-to-shell tricks ride in the same way.
- **Plugins** bundle the first two together and ship through marketplaces with uneven vetting, so a single install can bring in both an MCP server and a skill you never opened.

I'll show where each one lives on disk, why the usual tooling misses it.

In the agentic AI space, standards like MCP and A2A and a growing OSS ecosystem are evolving. Yet building a real multi-agent system requires more than a single framework or protocol. It involves integrating multiple OSS components and adjacent specifications across areas such as agent-to-agent communication, orchestration, authentication, and observability. There is limited shared understanding of how to combine them and what architectural considerations and integration gaps emerge.

This session shares our work on organizing the landscape of OSS-based agentic AI stacks, and on designing architectures built around MCP, A2A, and representative OSS, including prototyping through reference implementations. We explore several architectural patterns from a whole-system perspective. With enterprise use in mind, our scope also covers cross-cutting concerns such as authentication and observability. (LLMs are currently proprietary.)

Through this work, we examine what each OSS layer solves and does not solve, and highlight cross-layer concerns that emerge only when components are integrated as a multi-agent system. We share these observations with a demo of the reference implementation.

Most "human-in-the-loop" agent systems assume the human can specify success up front: a passing test, green CI, a structured eval. What if the human's taste is the spec?

This talk presents YouAndOrchestra (YaO), an open-source agentic music composition system on Claude Code. YaO orchestrates seven role-based subagents — Producer, Composer, Harmony Theorist, Rhythm Architect, Orchestrator, Mix Engineer, Adversarial Critic — turning natural language into a score evaluated across six dimensions, every note carrying provenance.

https://github.com/shibuiwilliam/YouAndOrchestra

Three collaboration patterns from iteration:
1. Three-tier feedback. Users rewrite the YAML spec, regenerate a section, or pin feedback to a bar, beat, and instrument. Choosing the level is itself a UX problem.
2. Conductor loop with a critic gate. Generate, evaluate, adapt, regenerate runs up to three iterations, with critics gating before notes are placed.
3. Provenance as trust substrate. /explain queries an append-only causal graph — "why did the chorus modulate to the relative minor?"

Attendees leave with patterns and open-source code for agent systems where the human stays in the seat of judgment.

AI coding agents now generate UI from component libraries. Most teams write component markdown files and expect agents to take it from there. The docs were complete. Agents still got it wrong.

Sitting with engineers in code review, the same things kept surfacing: the agent picked a visually similar but wrong component; it invented props; it read "Tag" as a UI primitive when the codebase meant a security concept. One author. No review process. A library too large for any agent to navigate without a map.

Not a component library talk. A talk about what the workflow was missing when the docs were already done.

I'll walk through the workflow that came out of those sessions: why a component file needs more than one author before agents can trust it; how an index changes what agents can find; and the naming decision that was invisible to humans and catastrophic for agents. Including the moment the team realized the problem wasn't the docs.

You'll leave with one reframe: a component library has always had two users. It now has a third. Here is what the workflow looks like when you build for all three.

AI systems are increasingly evaluated using benchmarks designed for individual components: Word Error Rate (WER) for speech recognition, MOS for speech synthesis, latency for infrastructure, and task success for agents. Yet users experience none of these components in isolation when using voice agents, they experience conversations.

Voice agents expose the limitations of traditional evaluation more clearly than any other AI system. An agent can achieve state-of-the-art WER, MOS, and latency metrics while still delivering a frustrating user experience.

This talk explores why established metrics are becoming insufficient for real-time AI applications and introduces a framework for evaluating voice agents holistically. We will examine concepts such as semantic understanding versus transcription accuracy, latency distributions versus averages, interruption handling, recovery from errors, and conversation-level success metrics.

Through real-world examples from production voice systems, attendees will learn how to move beyond component benchmarks and begin measuring what ultimately matters: whether an AI system successfully helps a user achieve their goal.

Technical debt lives in code. Cognitive debt lives in your head. Intent debt, Addy Osmani's term for the goals, constraints, and rationale behind a decision that never got written down, lives nowhere. It's the one debt agents can't pay down: an agent drafting a spec fills the gap with a confident guess, and the guess is usually wrong.

This talk covers building context graphs that capture the why: connecting decisions to the document threads and ticket discussions where humans actually made them, then exposing that structure to agents alongside code and data. I'll draw on an open-source toolkit that bootstraps context graphs from existing work artifacts (workspace threads, ticket histories) and the modeling questions that turned out hard: what separates a decision from a discussion, and when capture should run as a background process versus an explicit act.

Vendors now race to pitch "context layers for agents." I'll argue the differentiator isn't collection but connection: rationale linked to the entities, people, and prior choices it affects: queryable, not just retrievable.

You'll leave with patterns for making the why available to every agent that touches your work.