AGNTCon + MCPCon Japan 2026

AGENTS.md is the file that tells any coding agent how to work in your repo. One open AAIF standard, read by Codex, Cursor, Claude Code, and goose. But it is static. Written once, by hand. It drifts as the code moves. Auto-generate it and agents often get worse, following bloated rules and chasing dead paths. The agent fails the same way every run. Nothing feeds those failures back. The text that drives it never learns.

This talk show how to fix that with a layer on top of AGENTS.md that tunes it from the agent's own runs.The loop is small. Run a task. Reflect on the trajectory in plain language. Find what broke. Propose one targeted edit. Validate it against an eval harness before it sticks. Reflect, mutate, validate, select. Borrowed from reflective optimizers like GEPA. No RL. No fine-tuning. Just an agent learning from its mistakes.

The layer is tool-agnostic because AGENTS.md is, and it extends to MCP tool selection. We measure what moved, task success, edits per gain, token cost, regressions on a held-out set. We beat hand-written and auto-generated files. You leave with a layer you drop onto the AGENTS.md you already have.

From a green software perspective, waste in agentic AI comes not only from model choice, but also from workflow design. Agent workflows combine planning, retrieval, retries, memory, tools, and model calls. Poor controls can lead to large models for simple tasks, long histories, repeated retrieval, or needless tool calls, increasing compute, cost, and latency.

This talk presents a design-review approach for reducing unnecessary computation in agent workflows. As a case study, it uses Lean Agentic AI (https://github.com/navveenb/lean-agentic-ai) as an open-source workflow example. For each workflow step, it asks: Is an LLM needed? Is the model appropriate? Is context bounded? Could code, rules, or a smaller model replace a large-model call?

The goal is not precise carbon accounting. Instead, it identifies avoidable inference, oversized context, and needless tool calls before estimating CO2 emissions.

Takeaways:
* See how agent workflow design affects compute, cost, and latency.
* Understand how reducing unnecessary computation supports green software goals.
* Ask simple review questions to reduce unnecessary LLM calls, retrieval, memory, and tool use.

Kubernetes upgrades are high-stakes, deprecation-laden, and still mostly manual — most "AI for K8s upgrades" projects stop at a feasibility check. We went further: we built an agentic system that planned and executed a real cluster upgrade end to end, and in this talk we walk through exactly how it went, with the steps, evidence, and screenshots from our actual runs.

We'll break down the architecture we shipped — a planner → executor → verifier loop, deprecated-API and CRD/Helm compatibility analysis run before anything touched the cluster, a human-in-the-loop approval gate for irreversible steps, and health-gated automatic rollback. Using captured logs and screenshots, we'll show a real multi-node upgrade as it happened, the failure cases that nearly broke it (version skew, stuck drains, webhook deadlocks), and the decisions we deliberately refused to let the model make.

You leave with an open-source blueprint for autonomous infra agents with production-grade guardrails — plus real numbers on success rate, time saved, preflight catches, and rollbacks triggered.

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.

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.

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.

As autonomous agents move from experimental scripts to production systems, we’re exposing a massive flaw in how they’re built. We are giving LLMs the power to execute code, access files, and make network requests—essentially turning them into untrusted programs with direct authority over our infrastructure.

Prompt injection isn’t just a model quirk; it’s an open door to a massive attack surface. The moment an agent processes untrusted data, that input can hijack generated code, trigger outbound requests, and lead to data leaks or Server-Side Request Forgery (SSRF). Without proper guardrails, a highly capable agent is just a friendly interface over a Remote Code Execution (RCE) vulnerability.

This session reframes the entire security challenge. Instead of wasting time trying to make the model perfectly "safe," we’ll look at how to design infrastructure that stays secure even after the agent is compromised. By enforcing strict policy gates, we ensure that even if an agent is hijacked, it cannot access secrets, traverse your network, or execute privileged actions.

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.

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.