October 22-23, 2026 | San Jose, California
Times shown in PDT (UTC-7). Seating is first come, first served. IMPORTANT NOTE: Timing of sessions and room locations are subject to change.
Plan your sessions and build your personal agenda.
Learn how to use the event app and sync favorites across devices.
The Sessionize app allows you to build your schedule but is not a substitute for your event registration. You must be registered for AGNTCon North America 2026 to participate in the sessions. If you have not registered but would like to join us, please go to the event registration page to purchase a registration.
Build. Optimize. Deploy. Create on Arm.
Kick off AGNTCon + MCPCon North America week with hands-on experiences, live demos, Arm experts, and an after-hours event. Plus, receive an exclusive, Arm-powered digital badge that’s yours to personalize, play with at the event, and keep exploring at home.
Learn more and register now for Arm Create here!
https://events.arm.com/createatpytorch2026?utm_source=events&utm_medium=sponsored-content&utm_content=landingpage&utm_campaign=mk24_developer_pytorch
Date: October 19, 2026
Time: 10:00 AM – 9:00 PM PDT
Location: The Tech Interactive
Address: 201 S. Market St. San Jose, CA 95113
Every autonomous agent you ship is also an autonomous buyer, spending tokens on models, tools, and retries that nobody explicitly approved. But tokens are only half the ledger. At scale the binding constraint is energy, and the metric that matters shifts from tokens consumed to intelligence delivered per watt. Both are the same question: how much useful value are we getting per unit of spend? That question belongs in your design reviews next to latency and reliability, and the discipline to answer it (Tokenomics), has to be neutral, open, and community-built.
The first generation of AI agents lived in isolated chat sessions. But for agents to contribute meaningful work, they need more than a conversation—they need shared context, durable identity, governed access to tools, and clear paths for delegation and review. At Block, we’re building an integrated environment that connects individual agentic development, team collaboration, and a shared capabilities layer for accessing the systems that run our business. In this keynote, we’ll share the architecture and operating model behind that shift, including how people and agents coordinate work, how permissions and identity carry across tools, and how automation and model routing help the system operate at scale.
Transforming AI inference from a centralized bottleneck into an intelligent, globally distributed compute cache that instantly adapts to user demand.
How do you stop an AI agent from leaking API Keys, OAuth tokens, or secret credentials? "Hey, here is my API key, can you do this for me" an AI agent can easily ask another agent/API/MCP server. The answer is simple. Don't give them any credentials. So how do they do any meaningful work then? Inject the credentials on egress. In this quick session, we'll look at credential brokering for AI agents and how agentgateways can be used for this.
Most teams ship AI agents the same way: run a few prompts, eyeball the output, decide it "looks good," ship it. That isn't testing, that's vibes. Vibes don't catch regressions, don't survive a prompt change, and don't tell you whether a new model is actually better. Agents are too complicated and unpredictable for vibes-based testing to work.
In this talk I walk you through what real agent evaluation looks like: what evals are, why they're necessary, what separates a useful eval from one that just produces noise, and how to use eval results to actually ship better agents. You'll leave with a concrete framework for closing the loop: instrument, trace, evaluate, validate the evaluator, iterate.
The impulse to rewrite the auth stack for AI agents is strong, but we cannot design away the fundamental relationships standards protect. This session explores how MCP is reshaping OAuth—not abandoning it—to meet the ecosystem's unique challenges:
The "Unregistered Client" Problem: Traditional OAuth requires pre-registration. MCP breaks this. We’ll see how Client ID Metadata Documents (CIMD) allow agents to bring their own identities to arbitrary servers, how it improves on Dynamic Client Registration, and how to mitigate the risks of unregistered clients.
Separation of Concerns: Why your MCP server shouldn't be your Authorization Server. We’ll cover how Protected Resource Metadata (RFC 9728) enables dynamic auth server discovery, keeping agents lightweight and security boundaries clean.
Enterprise-Managed Authorization: To stop "click-through fatigue," we’ll introduce the Identity Assertion Authorization Grant. This moves consent to the enterprise policy layer, enabling secure, scalable adoption.
Join me to secure the agent ecosystem—from discovery to governance—not by reinventing the wheel, but by making incremental improvements to the way it turns.
Right now, developers are collecting Agent Skills like Pokémon.There's skills for planning, testing, reviewing PRs, and searching through documentation.
In this session, we'll break down what Agent Skills are, why they're becoming an important layer in agent workflows, and how they give agents repeatable capabilities they can carry across tasks.
Then we'll put a few Skills into battle using Entire. You'll see how an agent can search past sessions, trace how a project evolved, uncover previous decisions, connect changes to commits, and rebuild the context behind the code without making you read every transcript yourself.
At Datadog, we ship more than 10,000 pull requests a week. At that scale, human reviewers can't catch every ticking time bomb — the missing timeout that causes a cascading failure, the silent behavioral change that breaks every caller at once, the cold cache that thundering-herds a dependency into the ground.
In this talk, we share how we built an agentic review system that catches these patterns automatically, before merge, on every high-risk PR. You'll learn how we combined risk scoring with fine-tuned models, tool-augmented LLM agents, and reflection loops to go from "this looks fine" to "here's the exact line that will page you at 3 AM — and here's the fix."
We'll walk through the hard lessons: what makes an LLM a good reliability reviewer, how to keep it focused on outages and not style nits, how reflection loops measurably improve flaws catching quality, and how to wire all of this into a production system your engineers will actually trust.
Whether you're building agentic tooling or just trying to scale code review, you'll leave with concrete patterns for putting LLMs on the critical path of your engineering workflow — without losing your oncall's sleep.
Modern AI systems are no longer limited by models alone. They are increasingly constrained by infrastructure scalability, attribution pipelines, reliability, latency, and operational complexity. In this session, Neelakshi Soni shares lessons from building and scaling high throughput distributed systems at Meta and Amazon that process millions of requests per second.
The talk covers real world engineering challenges in AI driven infrastructure, including attribution systems, config driven platform architectures, experimentation frameworks, performance optimization, and reliability engineering. Attendees will learn practical approaches for designing scalable backend systems, reducing operational overhead, improving developer velocity, and building production ready AI platforms that operate reliably at massive scale.
This session is intended for backend engineers, infrastructure engineers, AI platform teams, and software engineers building production AI systems.
Guardrails live inside the model, and a model can be talked out of them. This demo puts enforcement in the runtime instead, a single control plane that every agent tool call passes through. Your identity system and your own policies decide what each user's agent can see and do, and the runtime applies those rules and logs every call it allows or blocks. Watch it hold a wire transfer for human approval, strip customer PII from a response before the model reads it, and shut down a user who borrowed a colleague's connection to reach tools they were never granted.
As AI agents become more sophisticated, static front-end applications are increasingly becoming a bottleneck. When agents can reason, plan, and execute complex tasks, collapsing their outputs into a "wall of text" or standard markdown severely limits the user experience. Enter Generative UI (GenUI): an architecture where Large Language Models orchestrate interfaces in real-time or cached, adapting layouts, components, and data visualizations based on user intent and session context.
In this session, we will dive deep into A2UI (Agent-to-User Interface), the open-source toolkit shipped by Google that safely bridges the gap between autonomous AI agents and frontend clients. You will learn how A2UI uses a secure, declarative JSONL stream to send UI structures across trust boundaries without ever transmitting vulnerable executable code.
You own your own design system, A2UI let's agents drive whatever front end "catalog of components" you want to share. The client is in charge of this contract and the agent adjusts, natively "speaking" UI and dynamically construct interactive, brand-safe experiences across Web, Flutter, Android, and iOS.
MCP's authorization spec now points implementers to Client ID Metadata Documents (CIMD) as the preferred path when clients and servers have no prior relationship, with Dynamic Client Registration (DCR) as fallback. That shift changes how client identity is created, verified, rotated, cached, and audited.
For server authors, gateway operators, and client platform teams running auth across many providers. We unpack the spec change, show how CIMD fits the OAuth handshake, and map the open production problems: redirect URI trust, SSRF hardening, metadata caching, key rotation, revocation, and tenant isolation.
DCR creates operational pressure at scale: registration sprawl, stale records, tenant drift, unclear ownership. CIMD replaces much of that with stable HTTPS client identifiers backed by URL-resolved metadata. Grounded in running an MCP gateway, we walk through a migration matrix across DCR, pre-registration, and CIMD; a pattern for translating identity across heterogeneous servers; and an audit model preserving attribution from human to agent to tool to API.
Attendees leave with a model of MCP client identity in 2026, a decision tree for registration, and a checklist.
Multi-agent systems today compose across MCP servers, A2A agents, and agent skills — artifacts that live in separate registries with incompatible metadata formats. AI Catalog addresses this at the standard level: a typed JSON format that gives each artifact type a common envelope for identity, capability, and provenance, without replacing the formats each community has standardized.
What makes the standard operational is federation. AI Catalog's well-known discovery mechanism lets clients traverse distributed registries without a central index. ARD complements it with a user-facing API — enabling any code assistant (Claude, Copilot, Gemini) to discover AgentSkills, MCP servers, and A2A cards across federated catalogs, verify them cryptographically, and resolve them to a live endpoint without knowing the source registry.
The AGNTCY directory is the reference implementation — content management, multi-registry discovery, and federation end to end. We demo the full flow: publishing an AgentSkill, an MCP server, and an A2A card under the AI Catalog standard, federating them through ARD, and discovering them securely from a code assistant at runtime.
MCP and A2A set the stage for building systems of agents that interact with each other and legacy information systems.
Current multiagent systems in industry are limited to problem solving, where the agents are orchestrated to solve a problem for the same stakeholder (person or organization).
Orchestration is over-constrained and inapplicable when agents represent different stakeholders. We need protocols such as the Universal Commerce Protocol (UCP). However, current methods (as used for specifying UCP) are rigid and lack a formal model. Thus, they prevent us from benefiting from the power of modern AI.
This session will summarize years of peer-reviewed research on engineering multiagent systems.
(1) How to specify interaction protocols to gain high flexibility with correctness guarantees.
(2) How to program an agent to participate in a protocol, without being limited to message reactions.
(3) How to represent and reason about the social or business meaning of an interaction (for business agreements and safety guardrails).
The session will include examples, including a proper reconstruction of UCP, and brief demonstrations. The underlying code is open source.
A2A 1.0 is the first stable specification for agent-to-agent communication — tasks, agent cards, message parts, and a transport model designed for both cloud-native deployments and end devices. But the spec was designed to be extended, and understanding where core semantics end.
This session walks through A2A v1 at a technical level: how tasks are structured, what agent cards encode and how they are published for federated discovery via AI Catalog, and how the protocol adapts its transport model across cloud-native deployments and end devices.
The second half covers what's open: the extension mechanism that lets the ecosystem add capabilities without forking the spec, and custom protocol bindings that let you replace the default transport while preserving full A2A semantics. We walk through a concrete example — implementing a custom binding, registering an extension in an agent card, and verifying interoperability against the reference implementation.
The session closes with a practical framework: when should a new capability be an extension, when a new binding, and when does it belong in the core spec?
AI agents are becoming users of software — but most apps still only know how to authenticate humans.
Auth.md is an open spec for agent-native authentication: a way for AI agents to discover how to register for a service, prove identity, request scopes, receive tokens, and start using an API without breaking out of the agent workflow.
This talk introduces our work on Auth.md and the emerging pattern for AI agent auth standards — including agent-native signup, identity assertions, ID-JAG, delegated authorization, and service discovery through an auth.md file.
You’ll also see a live demo where an AI agent discovers that Cloudflare supports agent registration, uses an Acme identity to create an account, receives an API token and account ID, sets up the Wrangler CLI, connects to Firecrawl, and deploys a live app.
Auth.md is designed to help agents become legitimate users in your system — not fake humans, not spam, and not impersonators — but real agentic users with clear identity and authorization boundaries.
Everyone, and I mean everyone, is shipping an MCP server. How do you know if yours is any good?
At Honeycomb, we've been running MCP in production for over a year, and agentic use of our platform has skyrocketed — over 40% of weekly query volume now comes through agents rather than humans. That's great, except most observability tooling assumes a world where a person clicks through a coherent workflow you can see and reason about. Agents break that assumption: no stable session boundaries, non-deterministic call ordering, and a caller that'll fire a dozen speculative tool calls and abandon half of them.
So our challenge: how do we know whether agents are actually having a good experience with our MCP?
In this talk I'll cover how we instrumented high-fidelity tracing across our entire MCP server to profile real agent transactions and find where latency and confusion actually accumulate, and how we built a continuous feedback loop on that production data — with evals on agent workflows baked in — to keep optimizing context usage and output formats as new models and agent harnesses keep landing.
As enterprises rush to adopt AI agents, many teams skip the most important product question: should this workflow be agentic at all?
This session introduces a practical framework for deciding when an AI agent is the right solution, when a simpler automation or human-in-the-loop workflow is safer, and how to scope agentic systems around business value, autonomy, and risk. I’ll walk through how product and technical leaders can evaluate agent readiness across task complexity, tool use, data sensitivity, reversibility, permissioning, customer impact, and failure tolerance.
Drawing from experience building AI governance, LLM, and GenAI risk products in production environments, I’ll introduce a “blast radius” model for agent deployment: how to limit permissions, define escalation paths, monitor failure signals, and add guardrails before expanding autonomy.
Attendees will leave with a clear enterprise framework for evaluating agent use cases, communicating trade-offs with stakeholders, and designing safer agentic systems for real-world deployment.
Agent applications like OpenClaw have emerged as some of the most prominent use cases in the current AI landscape, driving substantial token consumption. However, keeping sandboxes running during idle periods is neither cost-efficient nor secure. Consequently, implementing intelligent hibernation and wake-up mechanisms while reliably preserving sandbox state has become a critical engineering challenge for production-grade Agent infrastructure.
This session presents a comprehensive overview of hibernation strategies deployed in real-world production environments. We will cover time-based hibernation, idle-state detection, scheduled task–triggered wake-ups, and traffic-driven activation. A key focus will be the integration of an IM gateway with the sandbox egress gateway, enabling on-demand wake-up of OpenClaw-like agents via instant messaging even after deep hibernation. Finally, we will share practical lessons learned from implementation, including strategies for handling wake-up failures and optimizing resume latency to ensure seamless user experiences.
While the "do you have to read the code" debate rages on, we've been hard at work figuring out how to get models to write code that gets better over time, not worse. We'll discuss why current model training approaches and benchmarks checking "do the tests pass" are not enough, and how we're approaching evaluating the long-term-quality of LLM-generated code.
The most important capabilities in an AI stack are the ability to choose which model you use, and the ability to control what data that model sees. LLMs are a commodity. Choice and control are the point.
Choice means picking the cheap model for routine lookups and the frontier model when it matters, on-prem model when the data can't leave the building and the freedom to swap any of it out at any time without rearchitecting anything. Control means the data architecture, not the model, decides what data an agent can see. The right MCP layer lets you define exactly what data each tool exposes, so data architects know precisely what's going into AI instead of hoping the model behaves. Trusting a model not to leak or misuse what it's been handed is a bet, not control.
Neither matter if the data isn't reachable. Most enterprises depend on harder data than the easy 80 percent of SaaS APIs MCP servers already cover: on-prem systems, CAD/BIM/GIS formats, regulated records under GDPR, HIPAA, or SOX, hybrid environments split by design. Leave that out of the MCP layer and choice and control both collapse, however good the model selection or governance policy is.
Drawing on three decades of spatial and enterprise data integration, and real patterns from building a system that’s both an MCP server and an MCP client, this talk covers what it takes to make hard, hybrid, and on-prem data first-class MCP tools, governed and audited as architecture so choice and control stay real and, not theoretical.
Most teams made a person the API between their agents and everyone else: copy the output into chat, paste the reply back into the harness. This hands-on workshop shows the alternative: put the agents where the work is. We use Buzz, Block's open source, channel-driven workspace where people and AI agents share conversations, repositories, and reviews.
We begin in the middle of a live project, with four people and a swarm of agents working across shared channels and code. Then we rewind and bring the room in. Attendees will join a shared Buzz community, work with an agent, form channels with other participants, and practice delegating, steering, reviewing, and coordinating work as it happens. Along the way, we examine how Buzz approaches portable identity, scoped capabilities, signed work, and collaboration across different agent runtimes and models.
By the end, the room itself becomes part of the workflow: everyone contributes code, assets, and reviews to one shared project in a Buzz-hosted Git repository. Bring a laptop. Leave with practical experience running many agents in one shared workspace, where the whole team can see, steer, and use them.
AI agents are no longer simple “prompt in, tokens out” applications. They branch, call tools, retry, verify, and manage long-lived context. Yet today’s serving stacks still expose a chatbot-shaped interface: submit a request, receive a token stream, and optimize from the outside.
This talk introduces Pie, an open-source programmable inference runtime for agent infrastructure (https://pie-project.org). Pie lets applications express inference-time control logic, such as branching, speculative execution, tool-aware scheduling, and workflow-specific KV cache management, in programs called Inferlets. Inferlets can be written in Rust, Python or JavaScript and compiled to run as a Wasm program close to the model runtime, behind the chat interface.
Using concrete workflow examples, I will show why many latency, cost, and quality optimizations require application knowledge that generic serving engines cannot see. I will then walk through Pie’s runtime model, inferlets, and how programmable serving complements MCP, tracing, sandboxes, memory layers, and deployment platforms.
Two years of MCP in production have helped us build practical security knowledge across the specification, the official SDKs, and some of the best practices that emerged from closely monitoring usage patterns at scale. This session distills some of this not-so-secret knowledge for MCP server and client developers.
To make this digestible, we will follow three threads. First of all, the specification: how MCP authorization builds on standard OAuth, how tokens get bound to the server they were issued for, and how clients identify themselves in a way servers can verify. Then, we'll talk about the SDKs and why we want developers to use those as their de-facto startring point with MCP. And lastly, we'll focus on practical concerns: consent, treating tool output as untrusted input, and where a model sits between an attacker and a user's data.
Server and client authors should leave better prepared to build secure MCP artifacts and gain a more comprehensive understanding of how they can contribute to securing the protocol itself.
With the growing number of Agentic AI Frameworks and a constantly evolving landscape of AI Agents, ensuring interoperability between agents built on different ecosystems has become a critical challenge. The A2A (Agent-to-Agent) protocol addresses this need by enabling standardized communication and coordination across diverse AI agents.
In this session, we will explore what A2A is, how it works, and how it compares to MCP. We’ll break down the A2A architecture and demonstrate how agents can seamlessly communicate and collaborate using this protocol. Attendees will gain a practical understanding through an end-to-end demo built on A2A.
We’ll also examine real-world use cases and discuss how A2A can be leveraged to build scalable, interoperable agent systems in production environments.
We know AI coding agents can write code fast. But that doesn't mean they should be trusted to write it well, safely, or in alignment with your engineering standards.
In this talk, I’ll show why many agent workflows could use a code quality enforcement layer before code generation even begins. Using an open-sourced tool called PolicyNIM, I’ll walk through an AI system that turns Markdown engineering policies into grounded, citeable guidance by retrieving evidence, reranking results, synthesizing structured recommendations, and failing closed when the evidence is too weak to trust.
At its core, this talk is about operationalizing discipline for coding agents. We’ll cover evaluation, traceability, explicit failure modes, and how the MCP can serve as a practical integration surface for coding agents like Codex and Claude Code.
You’ll leave with a concrete design pattern for building agent workflows that behave with evidence, constraints, and judgment.
What if your AI systems behaved less like unpredictable sidekicks and more like a coordinated team of superheroes? This session uses a fun, cinematic arc to explain a serious shift in AI operations: moving from prompt-driven improvisation to skills-as-policy.
Instead of vague instructions (“do something heroic”), skills give each agent a defined power, constraints, and mission parameters. Policy becomes the briefing that keeps the team aligned. Validation tracks act as the training montage that ensures every hero knows their moves before entering production.
We’ll break down how organizations can publish, version, and govern skills so agents execute consistently: no more drift, no more chaos, no more “creative interpretations.”
Attendees will leave with a practical blueprint for building AI systems that behave like a disciplined, interoperable league of specialists rather than a swarm of unpredictable interns.
The Model Context Protocol (MCP) has rapidly become the standard interface for connecting AI agents to enterprise tools and services. But as organizations deploy more agents, a new challenge emerges:
How does an agent know which tools—and which enterprise systems—it should consult in the first place?
Business questions rarely map to a single API. A request like ""What's our exposure to this customer?"" requires an understanding of enterprise concepts such as customers, contracts, incidents, dependencies, security posture, policies, and organizational ownership before any tool can be invoked. Those concepts span dozens of systems, each with its own APIs, permissions, and semantics.
This talk introduces the Enterprise Knowledge Layer, an architectural pattern that complements MCP by providing a shared semantic foundation for AI agents. Rather than hard-coding workflows or broadcasting requests to every available tool, the Enterprise Knowledge Layer interprets user intent, understands enterprise concepts, determines which systems are relevant, applies organizational policy, and assembles the context needed to answer a question or execute a task.
Through a live demonstration, we'll follow a single business question from natural language to execution. The Enterprise Knowledge Layer identifies the relevant concepts, selects the appropriate MCP servers, orchestrates data retrieval across multiple enterprise systems, and records the resulting decision, evidence, and provenance into a persistent context graph for future agents and human operators.
Attendees will see how this architecture enables production-ready agent systems that are more explainable, observable, and governable than isolated tool-calling agents—without sacrificing interoperability across models, frameworks, or vendors.
See Device Connect in action as an AI agent discovers and interacts with real-world devices. We’ll demo the end-to-end flow live, showing how developers can connect agents to device capabilities and extend agentic experiences beyond the cloud and into the physical world.
You wire up a framework, add tools, write a prompt. It works. Keep adding tools and your context fills up fast, leaving less room for the actual conversation. Try multi-turn and state bleeds between sessions. Run it overnight and it dies at step four, restarting from scratch.
None of this is the LLM's fault. It's the harness, everything between the model and the tools.
In this talk, I'll share what I learned building agentu across 27 releases. You'll walk away with patterns for scaling tools without eating your context window, composing multi-agent workflows with crash recovery, and wiring self-correction loops that fix problems instead of logging them. Live demos included 😉
Modern agentic workloads no longer fit the standard request-and-response pattern. Loops can run for longer, servers can push streamed results, and there is a clear need to steer work mid-flight. MCP has been growing to meet these requirements. This talk will discuss what message patterns are currently in the protocol and where it's going.
Most teams iterate on agents by manual checking. Try a question, fix what looks wrong, repeat. It works at first, but there's no way to harness what you find. Each issue gets fixed once and then disappears, so a later fix can quietly revive an old bug.
This talk presents a simple practice: treat every piece of feedback and every quality issue as a regression test, applying the discipline of TDD to agent development. Instead of fixing a bad response and moving on, it turns into a test suite scored automatically, so regressions surface immediately rather than in production.
The session walks through this loop end to end in MLflow, from capturing a failing trace to building a regression suite that grows alongside the agent.
Every multi-agent system hits the same wall: context isolation. Separate harnesses, sessions, and projects keep one agent's state out of another's, but they impose a synchronization tax — coordinate too loosely and your agents fork reality; too tightly and you reintroduce the bleed it was meant to prevent.
This talk treats that tax as a classic interface problem, already solved by microservices and, before them, by Parnas's 1972 case for information hiding. I'll walk through a coordination protocol I built and run across multiple agent harnesses — a reasoning context, a code-execution context, and a shared store — where each publishes a facade: a stable interface that exposes its decisions and state while hiding its internals.
Others consume them through a producer/consumer handshake — one proposes a compacted update for human approval, the other fetches it — and it refuses to fail silently: when an artifact can't be retrieved, it pushes back rather than confabulate.
You'll leave with portable patterns: publish facades, not raw context; never share the database; gate shared writes through a human; and treat silent retrieval failure as a bug, not a default.
Industry trends are pushing companies to use more AI, often "at all costs". However, once CFOs start seeing the bills, the reality of "at all costs" really starts to sink in, and we start to turn to more pragmatic approaches to AI budgets.
The first step to managing AI spend is to have good monitoring in place. You need to know who your big users are, and which projects or workflows are draining your token budget. The answers can often be surprising!
In this talk, I'll walk through a live demo of how you can set up monitoring across multiple providers, with centralized access, using agentgateway. We'll talk about what metrics are important to track, and some gateway patterns we can use to keep costs from becoming unmanageable, like token-based rate-limiting.
The full step-by-step demo will be available on Github and the audience can optionally follow along on their own machines.
As more companies adopt MCP, they run into tool sprawl fast. Duplicate servers pile up, authentication turns into a patchwork of one-off schemes, and there's no single place to set policy, observe behavior, or onboard new agents and systems. Most teams reach for a gateway to fix it, but routing every call through one entry point doesn't tell you which agent should get which tools, who's allowed to call what downstream, or how you'd know if something broke.
This talk names that pattern: a control plane that federates multiple MCP servers into curated tool surfaces for each agent, workflow, or IDE. Borrowing lessons from the API boom, we'll structure capabilities into layered building blocks: system access, reusable orchestration, and channel-specific experiences, so you avoid point-to-point spaghetti while keeping integrations composable.
You'll see a reference architecture that separates front-door caller identity from downstream tool authorization (scoped OAuth or API keys), supports tool allowlists and LLM-facing usage guidance, and adds the controls a real deployment needs: routing, versioning, rate limits, audit logs, end-to-end tracing.
You'll leave with a checklist for turning tool sprawl into a governed platform. One that stays interoperable as new agents, clients, and systems keep showing up.
An AI gateway is only as performant as the data layer powering it. Join Jerod Johnson, CData’s Director of Technology Evangelism, for a live walk through of the Connect AI Gateway, built to govern what agents do at the data layer, and ground them in context that spans the organization.
Your chat agent has cute loading states: "thinking", "percolating", "vibing" but your voice agents don't have this luxury. Anything past 1 second of dead air feels broken and your voice agent repeating a loading state verb isn't cute. This session will demonstrate what happens when agents designed for text meet a phone call and how to handle common issues like buying time, error states, and confirmations when voice is your interface. Attendees will leave with patterns to apply to integrate tools to your voice agents and create experiences your users won't hang up on.
Most MCP security conversations stop at prompt injection. Rug pull attacks are a different, nastier problem and they are already happening in production. Your agent approves a tool. The tool definition gets silently modified after approval. The agent keeps trusting it. No re-validation. No alerts. Nothing in your existing security stack catches it because nothing was built to watch for it.
Three real incidents from the past year made this concrete: a fake npm MCP package that built trust over 15 versions before exfiltrating emails, a gateway exposure that leaked credentials and conversation histories from 2000+ MCP instances, and a GitHub MCP injection that hijacked agents into pulling private repo data through a fully legitimate tool.
This session is a live demo of all three attack patterns against a real MCP setup, followed by a practical defense framework built around cryptographic tool identity, definition change detection, and runtime monitoring. You will see the attack land, see what traditional tooling misses, and then see the controls that actually catch it. Everything demoed is open source and reproducible.
Agent workloads are fundamentally different from chat. A single request can trigger tool calls, recursive planning, retries, and long-running loops, making costs difficult to predict and even harder to control.
In this talk, I'll explore the emerging challenge of agent inference economics through the lens of pre-execution cost estimation. I'll present research investigating whether prompt embeddings and other pre-generation signals can be used to estimate output length before a model generates a response.
We'll examine how these techniques can help address one of the core challenges in agent systems: making cost-aware decisions before execution.
I'll show how practitioners can adapt these ideas to build rough cost forecasts, enforce budget constraints, guide model routing decisions, and create more predictable agent systems.
Attendees will leave with a practical framework for managing agent costs before work begins rather than after the bill arrives.
As SRE teams adopt multi-agent systems, a new class of problem emerges: agents with conflicting objectives operating on the same infrastructure at the same time. Your remediation agent wants to spin up three new nodes to absorb a traffic spike. Your cost-optimization agent wants to terminate underutilized instances to hit budget targets. Both are correct. Both are about to make things worse.
This talk explores the real-world failure modes of multi-agent SRE systems – what happens when agents act on stale state, override each other's changes, or reach a deadlock – and how to design your way out of it. We'll cover conflict detection, priority hierarchies, shared state management, and when to hand control back to a human.
You'll leave with practical patterns for building multi-agent systems that disagree productively, rather than destructively.
Structured memory is a compact injection surface. If an agent reads context that says "always use the production database" and acts on it, the consequences are real. This talk presents a trust architecture for stored agent context: server-generated preambles that warn agents context was written by another agent and may be stale, risk classifications on write operations, provenance footers that record who wrote what and when, file anchors with commit-at-write hashes for staleness detection, and read-time verification guidance. We present evidence that trust preambles reduced one class of context contamination from 88.8% to 33.3% in controlled testing, while being transparent about which attack classes remain unmitigated. The principle: stored context should be useful but never trusted by default.
Enterprise AI initiatives are failing not because of the models, but because the API infrastructure supporting them is fragmented and not built for AI data flows. API sprawl scatters policies across gateways, agent frameworks, and context stores that don't communicate — making it impossible to govern GenAI and Agentic AI at scale. This session covers what full data path governance looks like and how API modernization is the critical first step to achieving it.
Join us during lunch for a dedicated space to connect, collaborate, and share knowledge. This gathering is designed to amplify voices, celebrate achievements, and foster peer mentorship among women and non-binary leaders in the agentic AI community.
Porting a frontier model to custom silicon requires deep Neuron expertise, days of iteration, and hard-won knowledge that rarely gets codified. Neuron Agentic Development automates this journey from Hugging Face model to optimized model running on AWS Trainium, AWS' custom AI accelerator used by leading providers. In this session, we'll demo using agentic loops to port a model, verify equivalence, and run optimization loops. We'll also share learnings from building loop engineering in specialized domains.
Tokenomics covers the full path from energy and capital into AI, efficiently consuming it, and delivering measurable business outcomes. That path has three stages, and the Tokenomics Foundation is building an open framework to map this new territory. These are the lessons that came out of the working sessions and discussions behind that framework, from the people building and living these problems. Open, neutral, and community-built under the Linux Foundation.
AI agents are getting good at taking action. The hard part isn't making them capable — it's knowing when to make them stop.
This talk walks the full spectrum of human-in-the-loop patterns: inline confirmations, out-of-band permission gates, and handing your agent a wallet with real money in it. Each fits a different level of consequence. Built around live demos that escalate in stakes with every step, you'll leave with a mental model and a reference architecture you can use the same day.
Agents made implementation nearly free — for you and for everyone pointing the same models at the same data. That's the Anything Trap: when anything can be built, everything converges. This keynote argues the value moved up the stack, from building to choosing. The one decision AI can't make is what deserves to exist. Five minutes on conviction, signal, and why agents build — but you choose.
Harnessed agents have become the dominant interaction and runtime pattern for agentic AI. Claude Code, Codex, and a fast-growing field of open source harnesses integrate models with MCP tools, skills, and plugins. These harnesses provide sandboxed execution, scoped environment access, and human-in-the-loop controls on the desktop. The industry's next shift is already underway: moving harnessed agents from the desktop onto shared infrastructure, where security, observability, and governance are consistent across every agent interaction. In this talk, we will explore how open source infrastructure can deliver secure, scalable harnessed agents beyond the desktop.
AI is reshaping the web from a place we navigate ourselves into an environment where agents can discover, interpret, and act on our behalf. This shift is creating new pathways, new user experiences, and new questions about what the web is becoming.
In this keynote, we’ll explore the rise of the agentic web: how AI is changing the composition of the internet, how emerging specifications like WebMCP are beginning to define new interaction patterns, and what this shift means for builders, platforms, security, and the future of user experience.
Most importantly, we’ll connect the vision to what’s possible today, what’s coming next, and how we can help shape an agentic web that expands what people and software can accomplish together.
As AI agents move to production, engineering teams face a growing set of challenges. How do you secure and govern MCP servers without modifying them? Route and fail over across multiple LLM providers? Enforce rate limits, access controls, and governance policies? Observe agent traffic, manage context growth, and scale operations across environments?
Rather than embedding these capabilities into every agent, MCP server, and application, organizations can adopt a single architectural pattern: the agent gateway.
An agent gateway acts as a unified control plane for AI systems. It can function as an MCP gateway, LLM gateway, inference gateway, and traditional API gateway, centralizing security, observability, routing, resilience, and policy enforcement across agents, tools, models, and services.
In this hands-on workshop, you'll learn how to secure and federate MCP servers without code changes, route and fail over LLM traffic across providers, enforce authentication and usage policies, and gain end-to-end visibility into agent interactions. Through live demos, you'll see how a single gateway layer simplifies operations while enabling secure, scalable, and governable AI systems.
I was a huge AI skeptic, and honestly, I still am, but I've been dragged kicking and screaming into this new world of agents. After working through the usual stages of grief, I had a revelation. It was never about who was better, me or the agent. It was what we could do together. A human assisted by AI can be far more effective than either an autonomous agent or a human working alone.
In my work as a PMC member on the Apache Iceberg and Polaris projects, I've found that AI-augmented workflows dramatically improve my ability to communicate, review, and build with the community.
In this talk, I'll show how I review incoming PRs, triage security issues, and build in OSS hand-in-hand with agents. I'll demo my custom orchestration framework and show how that enables my own code review. I'll walk through the skills I've designed for the unglamorous maintenance work of license compliance and build validation. Beyond my own workflow, I'll introduce Apache Magpie, an ASF-wide project aimed at bringing this kind of automation to every open source community at the foundation. Together as a community, and together with agents, we can do far more than we ever could apart.
MCP Apps – interactive UIs shipped as MCP resources – are becoming how agents deliver rich, stateful experiences instead of plain text. Most talks cover the app and client side. The harder, less-discussed half is the host: the runtime that renders untrusted third-party UI, bridges its postMessage calls to MCP tools, binds them to the right identity and session, sandboxes them, and does it with no central app store.
This session walks through building an open-source, self-hostable host for MCP Apps end to end: the ext-apps postMessage bridge and where the spec leaves gaps; identity-bound (not workspace-bound) sessions with per-call tool routing; sandboxing and trust boundaries for code you didn't write; and how supply-chain verification – signing, SBOMs, an MCP-native threat model – lets a self-hosted host install apps safely.
You'll leave knowing what it takes to run MCP Apps in production on infrastructure you control, and where the protocol still needs work.
It is tempting to treat open standards like wish lists: add a feature to a specification, and the ecosystem will follow. In reality, adoption depends on solving concrete interoperability problems, defining the smallest useful shared contract, and securing the support of implementers.
This talk explores the principles behind effective open standards, using Agent Plugins to show how ideas become interoperable implementations across an ecosystem.
In the era of agentic engineering, agents are generating code faster than humans are capable of reviewing thoroughly. In order to keep up while catching critical issues, it's crucial to make agents a part of our code review strategy and build systems that allow them to verify changes against our expected outcomes.
In this talk, I'll argue that the best AI Code Reviewer for your organization is the one that is equipped with the context and the tools to verify its claims thoroughly before surfacing them to the agents (and their humans) who are authoring the changes. After all, a reviewer is only as trustworthy as the consistency of its findings; when the signal gets drowned out by the noise, it takes immense effort to rebuild trust and convince authors to listen to the feedback.
I'll show how to use goose to build your own local-first code reviewer equipped with the context from your organization to use a network of subagents to find issues, verify them against your knowledgebase, and leverage best-in-class models to debate findings before they get surfaced on a changeset.
When AI agents call internal tools, enterprise teams face an old access-control problem in a new place. Each call needs to preserve who the user is, which agent is acting, and what that agent is allowed to access. Without that context, teams fall back to shared service accounts with broad permissions, losing the ability to authorize per user, enforce least privilege, and audit tool actions.
This talk shares a production architecture from a highly regulated enterprise AI agent platform. We faced real enterprise constraints: our corporate IdP would not directly trust the platform issuer, some providers bound tokens to a single audience, and OAuth handling needed to be centralized rather than reimplemented in every agent. To solve this, we used Keycloak as a token broker across IdP boundaries and introduced an agent catalog that governs which agents may call which tools, audiences, and scopes. This let us re-mint audience-specific user tokens, keep authorization decisions centralized, and preserve per-user auditability across tool calls.
Attendees will leave with a reference architecture for building user-scoped agent access without pushing OAuth complexity into every agent.
Not every tool a helpful agent needs is neatly available as an API or MCP server. But simply bolting Playwright onto your agent often doesn’t get you far.
In this talk I’ll cover five different techniques you can use to equip your agents to master the World Wide Web, with live demos of each. I’ll go deep on how to get the most out of vanilla Codex and Claude, how to build your own browser agents, and then come full circle and show a self-healing approach which barely uses a browser at all. We’ll also cover some Temporal fundamentals along the way.
You’ll walk away from this talk with a deeper understanding of how to wield browser agents and an invite to my platform so you, too, can secure your ideal seating on your flight home.
Every organization has workflows buried in back-end systems – work orders, field reporting, asset tracking. They work fine. But AI agents can't reach them. This demo shows what changes when they can.
The remarkable part: the underlying workflow already existed. It was built years ago. The only new step was exposing it to the AI, and that took under seven minutes – with no code written by anyone.
For enterprise, the message is simple. You don't need to rebuild anything. Your business logic, your data rules, your integrations – they're already done.
The missing piece was a way for AI to call them safely. That piece now exists, and getting there requires neither a developer nor any knowledge of the technology underneath.
The question isn't whether your operations are AI-ready. It's how quickly you can flip the switch.
When people talk about "open source" in today's AI & ML landscape, they likely think of open models and kick off another debate between "open weights" and truly "open source" models. But open source goes beyond models… it's behind the most well-known and critical pieces of the ecosystem, from training to chunking data & embedding for RAG to inference to scaling, evals, observability, and optimization. Open source is everywhere and driving much of the AI ecosystem. For this session, we invite technical practitioners and engineering leaders to join Red Hat and open source expert Wesley Chun to learn what some of these critical pieces are, including but not limited to: PyTorch, vLLM, llm-d, OpenShell, OGX (formerly Llama Stack), Docling, and others.
A panel discussion with Technical Council members and stewards of UCP. Learn about the current state, current work, and future plans and evolution of agentic commerce.
Production agentic pipelines are failing in a pattern nobody has named yet. An agent introduces a dependency, another builds on it, a third deploys it and by the time a human reviews, a vulnerable package is three layers deep in a system that shipped last Tuesday.
This is generation-verification asymmetry: the mismatch between an LLM's near-zero cost of generation and the non-trivial cost of authoritative verification. Every unverified agent turn is a compounding liability. As pipelines grow from single tool calls to multi-turn autonomous workflows, the blast radius of one unverified decision in step two is embedded in everything that follows.
This talk opens with the failure: a live agent loop shipping a real vulnerable dependency undetected. Then the same loop with verification-first MCP tooling catching it before merge no human in the loop. The delta between those two runs is the entire argument.
From there: the compound risk model, verification-first MCP server design patterns, a full pipeline demo composing dependency scanning, SBOM generation, and policy gating as MCP tool calls, and an anti-pattern taxonomy separating genuine verification from simulated verification.
AI agents already use your web app. They're just doing it poorly: screen-scraping, driving Playwright MCP through human-shaped UIs, and working around frontends never built for them.
WebMCP changes the contract. A new rising W3C standard, it brings MCP into the frontend: apps register structured, discoverable tools that agents call, reusing your existing auth, personalization, and business logic. Going agent-ready this way can be much faster than traditional MCP servers.
This talk starts with the basics: registering tools, defining schemas, and making frontend functions agent-callable. We’ll use Claude Desktop to drive a frontend-only document-retrieval app via WebMCP.
Then, we’ll push the frontend even further with a research assistant running fully in-browser, featuring multi-agent coordination, semantic search, multiple WebMCP tools, and on-device models. Navigating some stumbling blocks and hacks, we’ll tour the impressive world of web-based AI and agents
You'll walk away with an introduction to the frontend-for-agents landscape and concrete next steps to prototype against WebMCP and start building today for the AI agents arriving tomorrow.
A single agent calling one tool is a demo. Production agentic systems are fleets of agents that must discover each other's capabilities, hand off work, share context, and keep running when a component fails, across runtimes and tools never designed to cooperate. That interoperability problem is what open protocols like MCP exist to solve.
This talk distills patterns from running multi-agent systems across three production domains: a public-safety platform that tracked 558,000+ people and pre-empted nearly 400 overcrowding incidents, a banking fleet of agents, and a clinical-assistance system bound by strict accuracy and audit rules. The hard problem was the same: how do heterogeneous agents and tools talk without bespoke glue for every pair?
We cover how a standardised context-and-tool layer like MCP becomes the coordination layer, plus patterns: orchestration versus choreography, capability- and content-based routing, shared state without coupling or silent drift, and resilience adapted to model non-determinism. Attendees leave with a vendor-neutral model for when a workload needs multiple agents and patterns for systems that stay observable and resilient in production.
AT&T, an enterprise with 130,000 employees, has a sprawling HR ecosystem that spans many environments, policies, teams and business processes. As a result, even basic HR tasks can be difficult to navigate efficiently. So, AT&T is building an agentic front door for HR, Ask AT&T for HR, to map employee needs to practical process workflows. Unlike many AI solutions, this is not a Q&A chatbot that simply redirects users to other systems. It's a complex, multi-agent system with secure, live integrations into backend HR systems. The platform uses an orchestrator to coordinate 100+ agents, each mapped to a distinct business process. The architecture combines publicly available and bespoke MCPs to connect agents to various enterprise systems, allowing agents to perform HR-related tasks within a single user interface.
This session will focus on the cutting-edge architecture behind Ask AT&T for HR, which relies on reusable workflow patterns, MCP tools that connect to backend systems, deep agents that communicate via an orchestrator, and a SOX-compliant task engine that sends tasks to designated employees while allowing paused workflows to resume where they left off once the task is complete.
Agents with full access are useful but dangerous. Agents with restricted access are safe but less capable. Agents with HITL lack autonomy and rely on consent-fatigued babysitters. It's tempting to try to retrofit OAuth, stitch in a vendor gateway, or sandbox everything. However, a great open standard for agent access has quietly existed for years. Now learn how to use Token Exchange and just-in-time policy to govern agents and give them autonomy, capability, AND security… without half measures, compromises, or –dangerously-skip-permissions.
Learn how to deploy and operate a resilient, air-gapped AI agent platform tailored for harsh industrial environments, including smart factories, offshore oil rigs, and cargo ships. This session demonstrates a production-grade, open-source stack built on Red Hat, Kubernetes, ArgoCD, Keycloak, APISIX, Temporal, and Hitachi Agentic Runtime designed for 24/7 operational continuity without internet connectivity. Discover how to run, orchestrate, and observe stateful LangGraph and Agent Development Kit (ADK) agents directly on the plant floor and remote edge locations with zero telemetry leaks and industrial-grade reliability.
See how organizations can bring trusted, practitioner expertise directly into AI workflows like Claude, Copilot, and coding environments. We’ll demonstrate how grounding AI in authoritative sources improves technical decisions, code quality, and confidence without slowing teams down.
As AI assistants grow autonomous, agents are becoming the web's leading users – bot traffic recently surpassed human traffic, and everyone's racing to be "agent ready." But what does that mean? And can we, as humans, even define it?
Agents need to discover, identify, authenticate, pay, use your tools, and retrieve your data – ideally headlessly. When headless falls short, they spin up a browser. Standards like WebMCP assume agents use your actual site. So where does "agent readiness" lie, and what do agents really want? llms.txt? Auth protocols? Any of it?
The problem with guessing: every "best practices" article goes obsolete the moment models improve. We keep designing for last month's agents. So how do we keep the web agent-friendly in a way that survives the next model release?
We've researched how agents really use the web – how they discover, interact, authenticate, and pay, what they look for, what they fall back to, and what drives their choices at each step of the agentic journey.
I'll share the key (and sometimes surprising) findings, a framework for becoming and staying agent-ready, and what this means for the web as we know it.
Enterprise teams often route many agents through a shared MCP deployment with one service account — no per-user RBAC. Agents can end up accessing Jira or Slack data beyond what each triggering user is actually permitted to see.
OAuth 2.1 is right for interactive agents. Client Credentials works headless but gives the agent its own identity — not the user's downstream permissions. RFC 8693 fits cross-domain services like Atlassian Cloud or GitHub.com. It's the wrong tool when the downstream service already validates your corporate identity provider's token natively — you'd be exchanging a token it already accepts.
I contributed header forwarding to Envoy AI Gateway (PR #2047, v0.6): the gateway forwards the user's existing corporate identity per-backend, per-call. Jira enforces that user's RBAC, Slack scopes to their channels — no OAuth infrastructure, no IT setup, one MCPRoute config change across many backends and tools. The identity already existed. It just wasn't flowing through.
This talk maps the decision framework across all four auth patterns, covers production security invariants, and closes with a verified Vault + ESO pattern — MCP credentials rotating live without pod restart.
AGENTS.md, the third AAIF founding project alongside MCP and goose has been quietly adopted by thousands of repos with almost no community discussion of what makes a good one. We will share a field experience of maintaining AGENTS.md across three open-source monorepos: where it lives (root vs per-package), what it contains that actually moves the needle (build commands, test commands, the forbidden directories), how it pairs with copilot-instructions.md and CLAUDE.md, and three concrete metrics by which the team measured whether the file was working (PR-from-agent merge rate, test-pass-rate on first try, human-edit count).
As someone with no prior experience in experimenting with Claude Code, much less develop a plugin to augment experiences of certain developers, co-developing a plugin specifically for mixed Rust-Python project maintainers with proved rather enlightening.
This plugin, which extends code review on such projects with LLM-driven insights, reveals a meandering journey of me designing and refining it: from leveraging Rust’s ecosystem to integrating AI into developer workflows. This talk will share lessons on modular design for extensibility, balancing automation with human judgment, and ensuring adoption through clear documentation. Testing it on real Python projects wrapping around native extensions written in Rust revealed trade-offs between innovation and usability, offering practical guidance for aspiring Claude Code plugin developers.
Most of the AI-for-engineering conversation runs in one direction: humans tell agents what to do, and agents produce code. But for high-velocity teams, the more interesting flow runs the other way, production telling the agents what is actually happening, so they can fix, refactor, and keep shipping without drifting away from reality.
This talk is about that reverse loop. It looks at what changes when the systems we operate start moving faster than the people who own them, the failure modes that quietly become normal when agents work without ground truth, and the durable plumbing that keeps them honest: traces, error budgets, customer signal, SLO breaches, incident timelines, all fed back as first-class inputs to the tools doing the writing.
If the broader AI shift is changing what it means to author code, this is the operational half of that story: the feedback infrastructure that makes the new way of working actually safe to run.
AI systems need more than intelligence; they need context that persists. Without it, even strong models can misinterpret information, lose decision rationale, or repeat the same mistakes. Context Graphs have emerged as a practical pattern for agentic AI: a living graph that captures not only what was retrieved or known, but how context led to actions through tool calls, constraints, policies, and outcomes, stitched across entities and time so precedent becomes searchable.
This talk explores context engineering as the discipline of designing that context layer, and shows how context graphs complement retrieval by enabling multi-hop, structured context assembly (building on GraphRAG-style hierarchical summaries) while improving explainability and evaluation. Attendees will leave with a practical understanding of how to build context pipelines that combine contextual retrieval with persistent memory and provenance, and why context graphs are becoming central to trustworthy, enterprise-ready AI systems.
One agent invocation fans out into dozens of model calls and tool calls, across shared inference, shared retrieval, and shared infrastructure. By the time it shows up on a bill it is one anonymous number billed to whoever provisioned the cluster. Tags cannot decompose it, and a gateway only sees the traffic that went through the gateway. This session shows a different approach: read the runtime instead of the invoice. We will put a live agent workload on screen and break a single shared pod down to the team, feature, and customer that actually caused the spend, with no tags, no SDKs, and no code changes.
An AI agent with access to private data, exposure to untrusted content, and a path to send data out is structurally exploitable: no amount of system prompt hardening can close this. The model following your access-control instruction is the same model following an attacker's injected one. Simon Willison, in an essay identifying the threat, named it the "lethal trifecta." Many teams still rely on system prompts, and injection studies show that's illusion, not control.
This hands-on workshop builds the architectural alternative: making the capabilities an agent can reach as small as its role requires, so a compromised agent's blast radius is bounded by design. You'll take a multi-persona agent system and design its capability surfaces so no single caller's namespace holds all three legs of the trifecta. We'll walk an enforcement spectrum: hardcoded tool lists, gateway filtering, structural separation. We'll look at how to evaluate your system against a clear litmus test: can your system prompt leak and your tool list be published without compromising access control?
You'll leave with working diagnostic techniques, practice spotting anti-patterns and applying mitigation strategies.
Teams are building MCP servers, writing skills, and restructuring projects to make their services agent-friendly, but most of those decisions are made on hunches. General eval tools tell you if something passed or failed, but not how your service performed or what the agent's experience was along the way. In practice, we've seen agents struggle silently between start and finish and route around MCP servers entirely, meaning well-built tooling gets ignored without anyone knowing why.
This talk is about building programmatic feedback loops for agent experience. We'll cover how to think about AX as something measurable across four dimensions: goal achievement, environment quality, service quality, and agent decision-making, and how to pinpoint where in the journey things break down.
Attendees will leave with a framework for measuring the real impact of their agent experience investments, alongside the tactical skills to write test scenarios with prompts, rubrics, and variants; compare configurations across agents like Goose, Claude, and Codex; and wire AX scoring into CI using AXIS (https://axis.run), an open source tool built for this purpose.
MCP adoption is accelerating across enterprises, and a new class of drift is emerging: agent architectures that look compliant in docs but diverge in code. Agents wire into tools they shouldn't reach, MCP servers register unapproved interfaces, and by the time anyone notices, the blast radius is wide and remediation is reactive.
This session shows how FINOS CALM, the open standard for machine-readable architecture, pairs with PR-time enforcement to govern MCP deployments before they merge. We'll walk through validation patterns: catching a coding agent that adds an MCP server with unapproved interfaces, detecting unauthorized nodes when an agent extends a system beyond its declared boundary, and flagging control violations. A live demo shows a coding agent blocked from making an unauthorized architectural change.
Attendees leave with a framework for treating MCP architecture as enforceable policy, plus an open-source CALM-backed MCP server they can run against their own graph. Especially relevant in regulated environments, but the patterns generalize to any team running agents in production.
Modernizing legacy data systems often fails at the "Human Bottleneck": months spent translating regulatory rules into API specs and production Spark code. At Capital One, we are breaking this cycle by moving mission-critical privacy ecosystems from cloud services to an Agentic Workflow.
This session deep-dives into a multi-agent system that automates the engineering lifecycle for FCRA-regulated pipelines—generating specs, writing code, and self-correcting via compliance guardrails.
Attendees will learn:
Agentic API Design: Using agents to ingest "Filter" requirements and generate standardized OpenAPI/Swagger specs.
The Automated Auditor: A "Validator Agent" that uses metadata to verify code against data integrity rules, ensuring an immutable audit trail.
Model-Driven Code Gen: Leveraging agents to consume specs and generate optimized code to kick off our Databricks Compute
Agents now move money, change records, and act across organizational boundaries. We have fast-growing
answers for who an agent is (identity, discovery) and what it may do (authorization) — but not an
independently verifiable record of what it actually did, checkable by a party that trusts neither
the operator nor the agent.
This talk makes the case for that missing "did" layer and shows it composing with the identity layer
— not replacing it. We'll cover the may/did distinction (approved ≠ executed ≠ confirmed); how a
tamper-evident, content-private action record references identity, delegation, and consent artifacts
by digest (MCP tool calls, Agent Cards, DID/VC, and MIT NANDA's AgentFacts) instead of absorbing
them; and how it anchors on open transparency-log standards (SCITT/COSE).
Live joint demo with MIT NANDA: an agent discovered and identified through NANDA takes a real action
in NandaTown, seals an action record that points back to its NANDA identity, and an open verifier
proves it — then we tamper with it and watch verification fail. You'll leave with an open, framework-
agnostic pattern for making agent actions provable, and a running verifier to try.
Agentic systems are great at reasoning through ambiguity, choosing tools, using skills, and adapting to context. But production workflows need deterministic execution, retries, auditability, observability, and operational control.
This talk explores how MCP and agent skills can connect to DAG-based orchestrators. Instead of letting agents repeatedly decide and execute the same fixed sequence of tool calls, we can use them to author deterministic workflows that are reusable, inspectable, parameterized, and replayable.
The session will cover practical patterns for MCP-connected workflows, including agent-authored DAGs, reusable task templates, runtime parameters, conditional execution, and human-in-the-loop control. The goal is to show how agents can reason where flexibility is needed, while deterministic workflows execute what needs to be reliable.
Goose began as an open-source, local-first AI agent built to perform real work—not merely answer questions. As teams inside and outside Block adapted Goose for increasingly diverse products and workflows, a more foundational opportunity emerged: separate the reusable agent runtime from any single interface or application. The result is the Goose Development Kit, an open-source Rust SDK for building model-agnostic, locally runnable agentic applications, including the agent loop, tool calling, context management, provider integration, and support for open protocols such as MCP and ACP.
This session traces GDK’s evolution from the original Goose project and explains how GDK relates to the Goose Reference Client, including Goose Desktop and CLI. We’ll provide a candid assessment of what is available today, what is still being extracted or standardized, and the roadmap toward stronger client-runtime separation, ACP interoperability, open plugin support, local and open models, orchestration, and easier embedding in custom applications.
We’ll also examine early adoption: Block’s shared Goose substrate already supports internal automation and customer-facing agents, while Stripe adapted Goose to power its Minions coding system. Finally, we’ll explore the likely next adopters—from enterprise AI platform teams and IDE developers to vertical-software companies that want agent capabilities without surrendering control to a single model or proprietary platform. Attendees will leave understanding where GDK fits in the agent stack and when to build on it rather than creating another agent harness from scratch.
It turns out the old engineering adage “composition over inheritance” applies to AI too. A Gmail agent is fundamentally better than a Gmail skill, and paired with a Sheets agent, a Notion agent, and a GitHub agent, you’ll significantly increase efficacy while reducing cost. Small models suddenly become viable, letting you put AI in front of your customers, not just your team. In this talk, we’ll discuss why this vision of the future hasn’t taken shape yet, and what you can do to build toward it today.
Most MCP clients still find servers the same two ways: a hardcoded URL, or a central catalog someone has to operate, secure, and be trusted to run. Both break as the agent population grows past what one operator can model — stale endpoints, scope creep on long-lived tokens, and a registry that takes rent on every relationship.
This talk shows a third path: publish and discover MCP servers over DNS, the naming and trust substrate the internet already runs. DNS-AID (an IETF-track draft and the related SDK is a Linux Foundation project) puts an agent's endpoint, capabilities, and cryptographic binding in SVCB and TLSA records under a domain its operator already controls — resolvable in one lookup, signed with DNSSEC, pinned with DANE, no central index in the path.
We'll walk the wire format: the name._agents.domain naming scheme, what goes in SVCB vs. TLSA, how the new MCP discovery binding maps onto it, and the three discovery states (known agent, known domain, neither). Then a live demo — publish an MCP server into a real zone, discover and invoke it from a fresh client, and watch a capability-policy mismatch get denied. All open source, all reproducible.
Your AI planner just wrote a workflow: "research in parallel across 3 agents, then synthesize, but only if confidence > 0.8." Now what runs it? Kubernetes orchestrates containers, not agent workflows. Kubeflow runs static DAGs, not plans generated at runtime. LangGraph and CrewAI lock you into one ecosystem and make you wire context by hand. A2A defines how agents talk, not how their work executes. The orchestration layer for dynamic multi-agent workflows is missing.
Agentry is an open-source gateway implementing the Agent Message Transfer Protocol (AMTP). Hand it a runtime plan and it parses the structure (parallel/sequential/conditional), coordinates each agent's dependencies, automatically shares context between steps (the synthesis agent sees the research with no manual wiring), and manages state, timeouts, and retries. Federated agent@domain addressing with DNS discovery lets one workflow span agents across frameworks and organizations, while a Context Graph records what was decided and why, so future runs query precedent, not a blank slate. You'll leave knowing when you need an orchestration engine rather than another framework, and how Agentry fits your MCP/A2A stack.
Most developer tools are built for one kind of user: a human at a terminal, or, more recently, an AI coding agent calling an API. Building well for both at the same time is a different design problem from either one alone.
This talk is about how to do it. The case study is Porthole, a CLI and MCP server that streams Android and Android TV emulators to a browser for a human and exposes the same controls to an AI Agent over MCP. The interesting move was treating the browser UI, the CLI, and the MCP server as three thin surfaces over a single set of primitives, with observability built into those primitives so an agent can verify each step it takes.
I’ll show the code, walk through the parts that surprised me, and pull out a handful of patterns that travel. Where to draw the line between primitives and workflows. Why observability tools end up being the most-called part of the API. You should leave able to look at a tool you maintain today and see what it would take to make it usable for both humans and agents.
Yeah, I compressed the interesting parts out of it. Try this:
Enterprise coding agents are only useful if they can edit files, run code, install dependencies, and access the network. Giving them broad access creates risk, but asking users to approve every action creates fatigue and trains them to click “allow.”
We'll explore how enterprises can configure agents with enough authority to complete real work with profiles that define where an agent can write, which network destinations it can reach, and which actions are always prohibited. A secure sandbox enforces those org defined boundaries, while an LLM judge evaluates ambiguous actions and escalates only when human input is necessary.
We will show how this works across common development tasks and how organizations can improve their configurations over time. Sandbox denials, judge decisions, task outcomes, and unnecessary prompts become a feedback cycle: proposed policy changes can be replayed against previous workflows, reviewed by administrators, and rolled out gradually.
Attendees will leave with a practical model for increasing agent autonomy without granting unrestricted access or turning users into permission reviewers.
Human-facing software doesn't ship without a gate: tests, type checks, linters, and security scans all have to pass first. Agent-native software (MCP servers and other tools) needs different testing standards, but mostly ships without any of it.
This session introduces a 4-layer automated release gate built for agent-invoked software:
Behavioral Evals: Testing tool selection and argument accuracy across AI clients against a baseline.
Protocol Compliance: Enforcing the MCP spec and OAuth 2.1.
Deterministic Checks: Catching malformed responses, timeouts, and auth failures.
Security: Guarding against prompt injection, tool-description poisoning, and OWASP Top 10.
What You'll Learn
We'll show how to combine rigid hard-fails with probabilistic gates to block broken code without stalling development. Crucially, these gates provide the feedback loop needed for self-improving software to autonomously optimize prompts and patch code in CI. Grounded in production failures, you'll leave with a concrete CI/CD checklist for safely shipping agent-facing tools.
Most AI maturity models measure one thing: how advanced are your tools? But tool sophistication alone doesn't predict collaboration quality. Imagine a hobbyist and Hendrix both hold the same guitar. The instrument is identical — what emerges is not.
This session introduces the Three Dimensions of AI Collaboration Maturity — a profession-agnostic framework for understanding where you are, where the growth opportunity lives, and what growth looks like:
Cognitive Complexity (Webb’s Depth of Knowledge – DOK) — How deeply are you thinking with AI?
Ways of Working (Tool Maturity – TM) — How well do your AI tools match the demands of your professional practice?
Delegation Trust (Agentic Delegation Trust – ADT) — How much autonomy do you grant AI, and how skillfully do you manage it?
Developed in practice, through building AI-assisted development workflows with Goose (Block's open-source AI agent), this framework started as an engineering tool (rp-why) and evolved into something applicable to any profession. Attendees will leave with a self-assessment they can apply immediately and a shared language for diagnosing AI adoption challenges on their teams.
Most MCP guides stop at "here is a server." Then you try to ship it, and the real questions begin.
I took mcp-gpu-server from a local script to a published package on PyPI, then registered it in the official MCP Registry. This talk walks that path end to end.
What the spec expects. What the Registry actually validates, and what it quietly does not. How a client is meant to discover your server, and where that still breaks.
I also sent patches to the Registry itself, so you get both views: the person publishing a server, and the person fixing the code that lists it.
No framework hype. A real package, a real Registry entry, real pull requests, and the parts that tripped me up. You leave able to publish your own MCP server and avoid the holes I fell into.
Picture the WHOLE software supply chain, beginning to end; it's a little like that olde tyme classic boardgame, "Candyland".
Designed NOT with preschoolers in mind, agentic AI Supply Chain Candy-Land style game is for everyone interested in learning about the software supply chain for agentic AI/ML. Travel through exotic locations like The Peppermint Forest of swirly-twirly dependencies, The Fudgy Swamp of Compliance, and much more!
Agentic AI is a fast-moving space within technology. However, everything we've learned in software engineering of the last few decades ALSO applies to this "new" world of agentic AI. We'll apply traditional software supply chain security techniques and, wherever able, tools to help developers and consumers win leveraging the agentic AI Supply Chain.
Through an analogy to an enjoyable and colorful game, with useful examples taken from standards and frameworks, the audience will have a better appreciation and ability to apply supply chain security concepts and tools to the development and support of agentic AI/ML-based solutions.
Research confirms what engineers discover in production: multi-agent AI systems fail at 41–86% across seven frameworks. MAST – the Multi-Agent Systems Failure Taxonomy (UC Berkeley, NeurIPS 2025) – identifies three root categories across 1,600+ execution traces: system design issues, inter-agent misalignment, and task verification failures.
This talk bridges MAST's diagnostic framework to Harness Engineering – a 4-layer production methodology that maps each failure category to a concrete response, built entirely on open source tooling.
I will go over two incidents that I faced and overcame. A customer service agent I built on LangGraph, and Zendesk corrupted hundreds of support tickets through one unvalidated tool call – silently, no errors, until we audited the data. A Kubernetes-hosted presales assistant I architected looped indefinitely on an out-of-distribution input and consumed real compute before the team caught it.
Attendees leave with a complete harness architecture – MCP-native tool contracts, LangGraph orchestration harnesses, Pydantic schema contracts, and Opik telemetry – mapped to MAST's failure taxonomy and ready to apply to any production agentic system today.
An agent that posts in a live, public channel plays by different rules than one in a notebook. It can be wrong in front of customers, spam a channel, talk over a human mid-reply, or get coaxed into things it shouldn’t do. Reliability here is barely about uptime. It’s about restraint: answer what you’re sure of, step back otherwise.
I’ll walk through a multi-channel first responder built to deflect the routine 60-70% and escalate the hard rest. The core move: classify every question by topic regardless of channel, then drive both the answer and the escalation target off one routing table, with per-channel scope in config. Three mechanisms enforce restraint: cross-post de-duplication, human-takeover backoff (the moment a human replies, it stands down), and confidence-gated answering that escalates when unsure. Hardening is built in: no execution layer, no secret handling, and skills guarded so an accidental run can’t post or pollute the learner. The tools it calls return structured signals (anomaly flags, event funnels) rather than raw logs, so the agent reasons over shaped data. The failure modes are universal to anything that talks in public.
Like the Agentic AI ecosystem based in the US, the Agentic AI ecosystem in China is also rapidly developing. However, the shape of the China Agentic AI ecosystem is quite different from that of the US ecosystem in many ways. Within China, although there is a web-based agentic ecosystem rooted in MCP like in the US, the leading agentic AI ecosystems are mobile-based rather than web-based. Furthermore, there is a much greater diversity of companies at each layer within the mobile-based agentic ecosystem, from device manufacturers to super-app developers to AI app developers to industry players such as finance organizations. Consequently, the range of protocols, open source projects, competition, and considerations around Agentic AI within the China ecosystem are in many ways much more complex and dynamic than in other markets.
This talk will provide an introduction to the China Agentic AI Ecosystem and also discuss its implications for the Global AAIF Community. In particular, as the leading mobile companies in the US start also to add increasing AI and Agentic AI capabilities to their platforms, might there be a future convergence in global requirements and cooperation around a broader set of Agentic AI open source technologies?
Most production agents are running on what amounts to a god-mode API key: broadly scoped, long-lived, and shared across teams. When the agent acts on a user's behalf, "who triggered this" and "who executed this" collapse into one unanswerable question. The security review queue becomes the bottleneck on every release.
This session presents a zero-trust identity pattern that gives agents a first-class, governable place in your identity stack. We cover: (1) why IAM systems designed for users and services break down when the principal is an autonomous agent; (2) the OAuth Subject vs. Actor claim distinction that captures the human-to-agent-to-tool chain at every hop; (3) Intersection Authorization, where effective permissions are computed dynamically; (4) immutable audit lineage; (5) how this composes across different frameworks (CrewAI, LangGraph, LlamaIndex) and protocols (MCP, AGENTS.md, custom).
Attendees leave with a deployable identity pattern, the math their security team needs to verify it, and lessons from rollouts in regulated industries.
Most agentic systems today rely on the model to orchestrate execution by chaining tool calls together. This works for simple tasks, but breaks down as workflows get longer, more data is passed around, and new tools are added. This leads to agents that are expensive, unreliable, and hard to operate.
The answer is clear: use code to do the tool call orchestration instead. The challenge with current approaches (like MCP CodeMode) is that agents write and run arbitrary code in production. That creates security and operations problems that relegates this class of agents to the sandbox, or a developer's machine.
Not anymore.
In this talk, Adam Terlson introduces and demonstrates a different approach: have the agent produce a static, declarative Finite State Machine (called a Charter), then interpret that Charter as code instead. The agent is up to 99% more context efficient, is able to effectively use 1000s of tools, and has many other benefits.
See for yourself how this architecture can make agents far more capable, reliable, observable, and secure at global scale—no sandbox required!
Most MCP tooling is built by developers, for developers. But if agentic AI is going to matter beyond writing code, someone has to figure out what it looks like for everyone else.
AgentOne is an open-source desktop AI agent built for people who will never write a prompt template or configure an MCP server by hand. Building it forced me to rethink assumptions the agent ecosystem takes for granted: How do you present tool approval to someone who doesn't know what a tool is? How does MCP server discovery work when your user just wants things to work? What does trust look like when the operator and the end user are the same non-developer?
This talk shares what I learned building AgentOne: the UX patterns, the architectural decisions, and the open questions we still haven't answered. The goal is to bring a perspective the ecosystem needs: what happens when MCP meets real users.
Hosted MCP servers usually give you two knobs: broad OAuth scopes upstream, and tool exposure at deploy time.
Your engineers may be allowed to do almost anything GitHub permits. Their agents should not. You might want an agent to open a pull request, but leave merging to a human. If you do not operate the hosted server, you cannot add that distinction there.
This talk shows how to close that gap with an identity-aware bridge. Pomerium sits in front of a hosted MCP server, handles OAuth for the user, evaluates per-tool and per-identity policy on each MCP call, and audits tool names and arguments. The interesting part is applying a proven proxy pattern to MCP so authorization happens at runtime, not deploy time.
I will demo this live against GitHub's hosted MCP server, with the audit log visible. The agent opens a pull request. Then we flip one policy toggle and the same agent is blocked from merging, without changing the client, server, or GitHub permissions.
GitHub is the marquee demo, but the pattern is broader: add policy and audit controls for hosted MCP servers you don't own.
Most agent stacks treat memory as storage: vector databases, summary tables, episodic logs, retrieval pipelines. The store answers what the agent saw. It does not answer where a particular memory came from, how confident the chain that produced it actually is, what depends on it, or what should happen when a request to forget arrives.
Long-running agents need that second set of answers. Without them, low-confidence input becomes high-confidence output along chains the agent never inspects, exceptions generalize into rules, and forget requests leave derivative memories untouched.
This talk advocates for a separate trust layer that sits between the agent and the memory store, independent of the agent framework and the backing store. A framework that's built on provenance walks across writes, confidence that cascades along the chain, forget operations and isolation guarantees when agents share state. An MCP server makes the layer accessible to any compliant client. The talk covers the design, and an open-source reference implementation.
Local agentic workflows on workstation-class systems create a new serving problem: not every step in an agent session needs the same model, but switching models at the wrong moment can break the workflow.
This talk presents a Mixture-of-Models design using vLLM Sleep Mode, where one model stays hot while others are hibernated and restored on demand, enabling practical multi-model serving on a single workstation.
The presentation centers on Session-Aware Agentic Routing (SAAR), recently introduced in vLLM Semantic Router for long-horizon agents.
SAAR adds session memory, hard locks around active tool loops and non-portable provider state, safe reset boundaries, and switch economics so routing decisions preserve continuity rather than optimize each turn in isolation.
In public results, SAAR reduced model switches by 79.29%, eliminated 3,836 unsafe switches, and reduced estimated cost by 78.71%.
The key takeaway is that for local agent systems, the challenge is not just model selection, but preserving tool-state continuity while making multi-model execution practical and reliable.
Your MCP server passes every test in Claude, then a user runs it in Cursor and it falls apart. Same server, different client, different outcome. Each client supports its own capabilities, manages context differently, provides different LLMs. Working in one client tells you almost nothing about production behavior across clients.
This session makes the case for automated cross-client evaluation: running eval suites against the same MCP server across many client configurations on every code change and deployment. We’ll share what we've seen for developers testing across 40,000+ MCP servers and 40,000+ client configurations:
Common ways things break: Why an agent might suddenly pick the wrong tool, mangle your data formatting, or secretly cut off your tool descriptions when switching between different apps.
The metrics to track: How to measure whether the agent actually picked the right tool, sent the right data, and what your exact success rate looks like on each specific client.
How to fix it automatically: How to move past just finding these bugs and start using automation to tweak your prompts and settings until they work flawlessly everywhere, not just on your laptop.
AI agents are moving from demos to production, acting on web apps on behalf of real users and teams. Yet many products fail them in subtle ways—not because the agents are bad, but because the apps were never designed to be operated by anything other than a human eye and mouse.
This talk introduces Agent Experience (AX) as a first-class concern, alongside UX for users and DX for developers, and argues that accessibility and testability standards are its foundation. I'll cover the common traps—brittle selectors, inaccessible UI patterns, and unstructured interactions—then run a live demo with NASA Open MCT, Playwright MCP, Playwright CLI, and Claude Code, showing how accessible markup and semantic structure measurably improve an agent's ability to understand, navigate, and act.
You'll leave with concrete steps to improve accessibility, testability, and agent compatibility in your own products—yielding not just better AI performance, but more robust, maintainable, and human-friendly apps. Because if an agent can't use your app, often neither can a screen reader.
Most agent failures are discussed as model failures. In production, many of the painful failures happen after the model has already done its job.
A tool-using agent turn crosses several boundaries: the user request, the model server, the tool-call decision, the client or orchestration layer that runs the tool, the structured result returned to the model, the resumed generation path, and the infrastructure that keeps state alive across that flow. Each boundary creates a new place for stale state, replayed tool results, lost context, hidden batching delays, bad routing, or partial failure to show up as a bad user experience.
This talk shares a practical systems model for building reliable MCP-style agent infrastructure. The core idea: treat an agent turn as a traceable transaction, not a single model call. We walk through a reference path where tool execution stays client-side, the inference layer detects tool-call intent, the API layer routes by model and session state, and the serving layer tracks KV cache, device health, shard placement, and queueing delay as first-class signals.
Most agent systems are built for observability, capturing computational signals like latency and error rates. That holds up fine and dandy until the question inevitably becomes whether specific workflows are worth their cost or whether automation is actually reducing spend…or just moving it somewhere less, well, visible.
The AGNTCon + MCPCon session will help attendees understand:
- Where the data models diverge and what that means when you try to answer questions neither system was designed for.
- What token spend misses. In production multi-agent systems, tool invocations, external API calls, human review, and downstream service calls typically dwarf token costs and arrive with no link back to the agent execution that triggered them.
- Why event-level records matter. Aggregated cost metrics answer questions about averages, but event-level records answer questions about specific executions and specific customers.
- What complete instrumentation looks like in production systems, including the specific edge cases in parallel tool calls and async agent chains where standard tracing patterns break down.
As coding agents become increasingly autonomous, the bottleneck has shifted to verification: how do we know if the code is correct? Code review cannot scale to the throughput of modern agents. And unit tests often miss issues that materialize across distributed services. Two techniques offer a path forward: deterministic simulation and universal properties. Distributed simulation makes it possible to test end-to-end systems with production conditions like network failures. Universal properties, like null-pointer freeness and durability, enable tests that are independent of application specifics and naturally scale with your codebase.
At AWS, we are putting these ideas together into Hydro: a distributed systems framework designed for agentic coding. Hydro offers a built in deterministic simulator that explores network interleaving, failures, and other sources of distributed bugs. And it uses the Rust type system to enforce universal properties of memory safety and determinism. In this talk, we'll explore the core principles behind Hydro, how it empowers agents to autonomously build correct systems, and take a peek at protocols for agent state we are building with Hydro!
Every major technological invention is accompanied by the invention of new economic mechanisms to take advantage of it. Think of how PageRank, pay per click advertising, and seamless online payments became the economic engines of the web, GPS-based location matching marketplaces became the basis for Uber, Lyft and the rest of the smartphone based on-demand economy, and YouTube ContentID for the creator economy. We don't yet have breakthrough market mechanisms for the AI economy. What are some of the missing mechanisms of the AI economy? How does an understanding that they haven't been invented yet change the discussion about AI and jobs for humans?
Most agent memory does not need a graph. If a saved value only has to point back to its source message, an ID could be sufficient. But when the same entities appear in different conversations and connect to other parts of the agent’s history. investigating that history is no longer as simple as following a single predefined lookup. It means traversing through the connections in memory from whichever part of the system raised the question.
In the live demo, I’ll connect an agent to an open source agent memory workspace through MCP and retrieve context from conversations outside its current session. I’ll then inspect the resulting context graph, following the connections between the retrieved entities and the earlier messages in which they appeared. Along the way, I’ll distinguish the links agent memory workspace creates during extraction from the provenance an application has to record deliberately.
When you start building AI agents, the infrastructure choices you make on day one shape how portable, observable, and production-ready your system will be on day 100. Most tutorials hand you a proprietary API key and wish you luck. But real agent systems need inference flexibility, structured observability, and a path from laptop to cluster that doesn't require a rewrite.
In this workshop, participants will build a working AI agent using the open-source agent-framework on open infrastructure. We'll wire up local LLM inference through OpenAI-compatible servers like Ollama and vLLM, instrument everything with OpenTelemetry, and stand up a full LGTM observability stack (Loki, Grafana, Tempo, Prometheus) to trace agent behavior and performance and Redis for durable chat history. Every component runs in Docker Compose locally and can port directly to Kubernetes with no code changes.
Participants will leave with a running agent stack they can extend, an understanding of how open inference servers decouple you from proprietary APIs, and hands-on experience wiring observability into agentic workloads.
Participants should bring a machine capable of running Docker and a local LLM server.
Discover how Google is leveraging the Universal Commerce Protocol (UCP) and the Agent Payments Protocol (AP2) to build the future of AI-driven shopping. This session explores how UCP powers features beyond Checkout like Universal Cart to operate smoothly across surfaces such as Search, Gemini, YouTube, and Gmail. We will go deeper into how UCP's discovery and pluggable capabilities-based architecture enables frictionless shopping experiences and reduces custom integrations.
Additionally, we will dive into UCP's expansion as a transactional backbone and detail how AP2 secures "Human Not Present" agentic payments through cryptographic proof of user intent. Attendees will leave with actionable takeaways, including the latest technical specifications, an understanding of the security models for agentic flows, and a clear road map for adopting the open protocols that will power the next generation of retail.
Every MCP demo shows three tools. Every enterprise deployment I've worked on ends up with sixty. Nobody talks about what happens in between.
When an agent has 100 tools available over MCP, the model has to pick the right one on every call. Tool descriptions start competing for attention. The context window fills up with tool metadata before the real prompt even lands. Selection accuracy that looked like 95% in the demo drops hard once the tool count grows. Latency climbs with it.
This talk is about that gap. What actually breaks as your MCP deployment grows from 5 tools to 50, and the patterns I've seen hold up in production.
I'll cover three things that worked: hierarchical tool routing, splitting one agent into specialized agents with curated tool subsets, and on-demand tool discovery with caching. I'll also be honest about what the 2026 MCP spec changes help with and what they leave unsolved.
This is grounded in real enterprise deployments, not benchmarks. If you're past the demo phase and your tool count is growing, this is the talk for you.
No slides full of buzzwords. Just what I've seen break and what fixed it.
Running production agents in 2026 means the ecosystem keeps shipping the things you were about to build. The answer isn't to wait or to build everything yourself. It's to build what you need now, adopt what ships, and build around it.
Our support agent at Adaptive is the case study. The first version ran on a Mac mini for three weeks. It got 614 invocations and saved CS roughly 30% of their time, but it was completely unreliable, so we pulled it. While we were rebuilding, Anthropic shipped scheduled managed agents and we adopted those immediately. We built our own Slack read-and-react bot and our own persistent event store to extend the harness for the workflow we needed.
The talk walks through the build vs. adopt vs. build-around decisions we made, the ones we got wrong, and the rule we use now for every new piece of agent infra.
Aimed at teams building production agents under real customer pressure, where workflows have to actually work but you can't bet the farm on building the whole platform yourself.
We standardized what agents know, what they can call, and how those capabilities are packaged and discovered. But the moment an agent starts working, its session is still trapped inside one chat window.
Agent Skills carry reusable know-how. MCP connects tools and live data. Agent Plugins bundle those capabilities for compatible clients. The next missing layer is the work itself.
Client-owned chats break down when agents run for hours, continue remotely, work in parallel, or need attention after the original window closes. This talk explores that missing layer through VS Code’s Agent Host and the open Agent Host Protocol (AHP). A dedicated host owns the live session while editors, browsers, the VS Code Agents window, and custom applications become clients for monitoring, reviewing, and steering it.
Through a multi-client demonstration, we’ll show why portable sessions require authoritative shared state—not another stream of chat events—and how AHP lets agent work outlive any one interface.
Every agent framework gives your AI tools. None of them ask: "should this agent be allowed to use this tool right now?"
We built an open-source pre-action authorization layer that intercepts tool calls before execution – not in the prompt, but in the framework hook. Then we let 1,149 people try to break it in a public CTF. Attack success rate dropped from 74.6% to 0%.
Outline:
1) The architectural gap: Why post-hoc guardrails (NeMo, Guardrails AI) can't prevent actions they only detect – and why pre-action authorization is a different layer entirely
- The OAP spec: How the Open Agent Passport works – agent identity, capability-scoped policies, and Ed25519-signed decisions at ~65ms p50
- Live CTF data: What 1,149 attackers actually tried, which attack patterns worked against unprotected agents, and why deterministic policy enforcement stopped all of them
4)The convergence: Why three independent groups (APort, Microsoft AGT, Airia) shipped the same architectural pattern within weeks of each other – and what that means for the stack
5)Live demo: I'll configure a passport, attach it to Claude Code, and show an allow and a deny in real-time with the audit trail
Most agentic systems in regulated industries face the same challenge: compliance, legal, and audit teams often reject deployment once they understand how LLMs make decisions. The popular “LLM calls tools in a loop” architecture is poorly suited for HIPAA, SOX, PCI-DSS, and similar requirements. Guardrails can reduce known risks, but they cannot guarantee compliance, safe behavior, or auditable outcomes.
This session presents an alternative architecture for trusted agents. Rather than placing the LLM at the center of decision-making, the model is limited to tasks such as translating human intent into specifications. Core reasoning is performed by deterministic systems using classical AI techniques, including knowledge representation, formal verification, and constraint-satisfaction solvers.
Using a production HIPAA-compliant healthcare staffing agent as a case study, the talk shows how natural-language requests become verified specifications, how staffing plans are generated, and how audit-ready evidence is maintained. Attendees will leave with a practical framework for building compliant, trustworthy agents in regulated environments.
The MCP ecosystem has a critical but underexplored attack surface: SSRF vulnerabilities in official server implementations. This talk presents Protocol Pivoting — a concrete attack chain where an attacker exploits HTTP fetch capabilities in official MCP servers to reach internal network services (Redis, SMTP, Elasticsearch) that should be network-isolated.
I discovered these vulnerabilities in official MCP server implementations from multiple major AI vendors through responsible disclosure (CVEs in progress). The attack operates at the network transport layer — undetectable by LLM-layer defenses.
I'll demonstrate:
• How a single SSRF in an MCP tool server enables cross-protocol lateral movement
• Internal service enumeration via timing and error analysis
• Bypassing network segmentation in enterprise AI deployments
• Live results from mcp-safeguard (pypi.org/project/mcp-safeguard), my open-source scanner
Attendees leave with detection patterns, mitigation strategies for MCP server developers, and access to the preprint: zenodo.org/records/20371152
Agents, when equipped with the right Skills and MCP servers, can accomplish nearly any task a human can do with a computer. Today, that typically involves one notable pre-requisite: human-initiated pre-installation of those Skills and MCP servers.
The new AI Catalog standard developed in collaboration between individuals from Anthropic, Google, Microsoft, Cisco, and others paves a path to eliminating that pre-requisite. By rallying around a standardized .well-known/ai-catalog.json URI, agents like Claude.ai, Claude Code, Goose, and others can accomplish mid-session discovery of artifacts like Skills and MCP servers. For example, if you didn't know a GitHub MCP server existed (or how to connect to it) when you asked your coding agent to perform a PR review, your coding agent can now automatically discover that MCP server and offer to install and connect to it before it even starts the review.
This dynamic unlocks a new service discovery economy embedded into agentic workflow UX we're already using. Instead of requiring users to have advance knowledge of what MCP servers they might want their coding agent to have access to, now their agents can recommend highly relevant services with a one-click installation experience.
Attend this session to learn the specifics of how this mechanism works, its limitations, and what's next.
Most multi-agent frameworks use request/response orchestration: a coordinator calls sub-agents and aggregates results. This works for simple pipelines but breaks down when agents must react to unpredictable events, handle variable-latency LLM calls, and recover from partial failures—the realities of production.
This talk presents event-driven multi-agent orchestration on streaming infrastructure. Agents subscribe to event streams, react independently, and communicate through a shared bus. The architecture borrows from microservices: choreography over orchestration, eventual consistency, and dead-letter queues for failure isolation.
We'll introduce the "fast path / smart path" pattern: splitting workloads between lightweight rule-based agents (sub-millisecond latency) and LLM-powered agents (deeper reasoning). Both consume from the same stream; the fast path handles volume, the smart path tackles complex cases. An event bus coordinates handoffs and retries.
Through production examples, we'll show how this delivers scalability, fault tolerance, and cost efficiency. Attendees leave with reusable patterns for resilient, distributed multi-agent systems.
The naive approach to MCP servers is to provide basic APIs to Agents. This approach “works” but we can go much further with MCP as an Agent Integration Interface that enables richer and more fluid experiences. For example, a common approach to understanding how users interact with web applications is to model the concept of a user session so that observability platforms can correlate all user interactions in a given session. MCP doesn’t have a built-in way to correlate interactions across a given multi-turn prompt or longer running session. But we can enhance MCP servers with correlation IDs to provide exactly these kinds of insights.
This session will dive into a number of patterns that enhance MCP to provide insights and more robust Agent Integration Interfaces. We will cover how to add correlation ids to MCP tool calls, automatic tool folding to reduce sequential tool calls, coercing an agent to support long-running task polling (for clients that don’t yet support MCP Tasks), and managed live server updates that don’t break connected users. These patterns will help attendees address real production challenges that impact users and operational capabilities.
Git gives us a way to automate just about anything. With Git hooks and off-the-shelf security tools, developers have been able to weave all sorts of checks into their Git rituals, 'shifting left' in order to eliminate security rework later. But Git was made for humans, and only the commit was meant to be shared.
Today, coding assistants like Cursor, Claude Code, and Copilot can read files, propose changes, run commands, and interact with project context, often across a messy workspace. In an agentic workflow, secrets leak through context, output, and history.
Fortunately, these tools have started supporting AI hooks, which allow you to move your testing closer to when the code and development artifacts are produced.
Come to this session if you want to learn:
– How hooks provide a practical pattern for catching mistakes before they leave a developer’s machine.
– Why AI coding tools like Cursor, Claude, and Copilot need guardrails beyond prompts and trust.
– How to use AI hooks, rules, and automated checks before agents edit files, run commands, or touch sensitive systems.
– How teams can reduce risk, improve consistency, and make safer contribution paths the default.
The November 2025 MCP spec release introduced tasks, a way to make tool calls async. But more than 7 months later (an eternity in AI-time) there are still NO clients that support it – not Claude, not Codex, not even goose! I believe there are two reasons: Designing the client experience when there are potentially 1000s of background tasks running on their own schedule and engaging humans at unpredictable times is a challenge. But even moreso, tasks place new infrastructure requirements on the client side (not just the server side). Spoiler: the first version of the MCP tasks protocol put a durability requirement on the server. The July 2026 release puts a durability requirement on the client.
This talk digs into all of those concerns through real implementations. We will derive the architectural elements that are needed on the client side (and a reminder of what is needed server side) and provide a reference implementation. You’ll come away with concrete practices for building robust, async MCP clients and servers, and a clearer mental model of the distributed systems issues the spec encodes.
Enterprise agentic systems are moving from single assistants to agent chains: Agent A spawns B, B delegates to C, and C invokes an MCP tool that writes to a system of record. The unit of risk is no longer just the tool call — it is the delegation edge. The key question: is each descendant operating within a valid, revocable, least-privilege authority chain tracing back to a consenting human or root principal?
Without that zero-trust chain, teams face confused-deputy attacks, delegation laundering, privilege creep, forged lineage, and audit trails that cannot prove who authorized what.
This session presents RDCP — the Recursive Delegation Capability Profile — a standards-first pattern for securing recursive delegation. RDCP composes identity, authorization, policy, revocation, and evidence standards into a practical control-plane architecture.
We will show cryptographic identity, signed spawn intent, grant-before-token issuance, OAuth Token Exchange/RAR, DPoP or mTLS child tokens, monotonic least-privilege attenuation, AuthZEN PDP decisions, MCP Gateway enforcement, subtree revocation, and tamper-evident receipts linking spawn → delegation → token issuance → tool call → outcome.
Running open models locally changes how engineers think about agent systems. Once models move from hosted APIs into self-managed infrastructure, problems that were previously hidden behind providers become operational realities: latency, orchestration, throughput, observability, GPU memory, tool-call reliability, evaluation variance, and cost control.
This talk shares lessons learned building and operating self-hosted agent systems with llama.cpp, vLLM, quantized models, local coding agents, and production-like homelab infrastructure. Using examples from Pedro CLI, multi-model serving, evaluation workflows, and distributed inference experiments, we will look at what changes when the model is no longer an API call but part of the platform.
Rather than focusing on benchmarks or hype, this session focuses on the operational work required to make open models useful in agent workflows: routing, retries, context management, observability, quantization tradeoffs, and failure recovery.
Attendees will leave with a practical model for deciding when self-hosting makes sense, what infrastructure problems to expect, and how to design open agent systems that are reliable enough to operate.
WebMCP is a way for an agent to interact with your website / UI.
MCP Apps are a way for a server to return UI to be displayed in the agent – for visualization, branding and the “last mile of interaction”.
These two technologies sit on both sides of the agentic-UI spectrum, and combining them completes the full cycle of human-agentic interactions.
By combining WebMCP with MCP Apps, you can expose your capabilities directly to an agent that rides alongside the user. This also allows the agent to use WebMCP to control an MCP Apps UI.
Walk away from this session with the ability to use WebMCP to let an agent drive your existing website, learn how to expose specific site functions (like "Compare Pricing") that the agent can render as an interactive, on-the-fly widget inside a chat sidecar with MCP Apps and build flows where the user handles the visual interaction, and the agent handles the heavy lifting. Understand the use cases and best practices for WebMCP and MCP Apps, and see how combining them usher in the new era of interfaces.
Enterprise adoption of the Model Context Protocol is accelerating, and MCP has become the primary way agents connect to enterprise tools and data. But MCP is only part of how agents act. Agents also run CLIs, execute Skills, and generate code that calls APIs directly. Governing MCP well matters. Governing everything else agents can do matters just as much.
Building MCP servers and writing Skills isn't particularly hard. The real challenges are deciding which actions agents are allowed to take, controlling who can take them, and proving it all later. These are architectural questions, and they need answers before agents scale across an organization.
In this workshop, we will:
1. Show how to control agent actions with policies that apply across MCP servers, CLIs, Skills, and agent-generated code — including allowlists, access control by users and groups, and human-in-the-loop approvals.
2. Explain why enterprises need managed registries for MCP servers and Skills, and how admin review and approval change the trust model.
3. Work through audit and compliance requirements: capturing complete logs of agent and tool activity, exporting to enterprise storage, and generating reports.
4. Demonstrate how to discover shadow AI — unmanaged agents, MCPs, and Skills already running in your organization — and how to block them or bring them under management.
5. Look at token usage and spend visibility by agent, user, and group.
You'll leave with a clear picture of the architectural decisions ahead of you, and a better sense of what your security team will require before signing off on scaling AI agents across your organization.
Agents are easy to demo but brutally hard to evaluate. Once your system handles planning and tool calls, traditional LLM evaluations—like exact match or eyeballing—fail entirely. You ship a prompt change and break edge cases invisibly.
This talk shares engineering lessons from building Evalbench, an open-source evaluation framework, and how we scaled it from NL2SQL testing to complex agent workflows. You’ll leave with a concrete blueprint to instrument your agents, including:
- Beyond the Final Answer: Measuring trajectory, tool accuracy, and sub-goals.
- Explainable Judges: Combining deterministic scorers with debuggable LLM judges.
- Modular Architecture: Inside Evalbench’s evaluators, scorers, and reporters.
- Production A/B Testing: Running rigorous experiments for model, prompt, or tool swaps
The first wave of MCP Apps shipped standalone tool surfaces, each with its own auth, routing, and conventions. That works for one app. It fails the moment a responder (an on-call engineer or an AI agent) has to move from a firing alert, to the trace that explains it, to the logs the span emitted, to the dashboard tracking the trend. Every hop loses context.
We took the opposite path. Our team built and operates OpenSearch observability as a single MCP server with shared capabilities: auth, time-and-data routing, correlation, saving, and inspectability, defined once at the server and inherited by every app. The result: 295 jobs across 15 families (triage, logs, traces, metrics, SLOs, agent observability, dashboards, ingestion, stack health) served by ~51 composable MCP apps, all sharing a universal traceId/spanId correlation pivot so context follows the responder across tools.
This talk walks through what that buys responders: faster jumps from alert to root cause, consistent auth and routing across clusters, correlation that just works, and how a five-person team ships two new apps a week without rebuilding the same plumbing.
That SKILL.md file you just installed to supercharge your AI coding agent? It might be exfiltrating your AWS credentials right now. Yikes. Just like with early npm, attackers are abusing various Agent Skill ecosystems to launch malware campaigns. So now AI builders rush to add Skills which inherit the agent's full execution environment, yet ToxicSkills research found 37% of nearly 4000 skills malware and other security weaknesses, and even one "security scanner" skill that was itself malware, ha! The next AI security frontier is hijacking the agent's own reasoning to suppress safety warnings. Here’s your chance to see in action how coding agents crumble under a malicious skill.
In this session you'll watch live hacking of a malicious skill and how it fools a coding agent for rogue actions, a prompt injection leaks your secrets over email, and a leaky skill passes credit card numbers straight through the LLM context. Then I’ll show you how to detect these malware and dangerous skill.md files and catch what every regex-based scanner misses. You'll leave with a concrete threat model for Agent Skills supply chains.
A Place for Mom has served senior care families for 20 years. In 2025 we built Grace — a B2C home care platform — AI-native from the first commit. Not "we added Copilot." Every layer runs with agentic tooling: planning, coding, review, deployment, observability. In production since November 2025.
July 2025 through May 2026: 3,478 PRs across four repos, 2,822 merged, 81% merge rate.
We built a five-layer stack. CLAUDE.md files give agents persistent context so they aren't starting fresh each session. Structured planning prevents the 200-lines-down-the-wrong-path failure mode. Git worktrees let parallel sessions run in isolation. A 10-stage multi-agent review pipeline with confidence scoring vets every PR. And platform-mcp — a Go service connecting Claude to New Relic, PagerDuty, Jira, GitHub, AWS, and Databricks through one endpoint — replaced six integrations.
The harder question is what that pace does to comprehension. Velocity is measurable. Understanding is not. When an engineer ships in two hours what took two days, do they understand it well enough to debug it at 2am?
We call this comprehension debt — and the guardrails built for code quality are the best defense.
OAuth scopes tell you an agent can write to your CRM. They don't tell you whether it should have written that. This session goes deep on intent-based authorization for agents: how to model agent identity distinctly from user identity, where policy decisions belong when the caller is nondeterministic, and what a real permission check looks like in an agentic call chain. Includes a recap of the concepts from our demo theater session, plus the architecture and failure modes we didn't have time for.
Payments can be complicated, especially for devs that are unfamiliar with how they work. And agents add an additional layer of complexity into the payments experience.
For instance, agents can call tools, but monetizing tools or purchasing resources still usually requires manual onboarding (accounts, keys, billing setup). This session will cover how to embed payments into agent tool flows using an open “challenge → fulfill → retry” pattern aligned with emerging agentic payments protocols (e.g., x402).
I’ll walk through the required components for embedding payments in agentic experiences: standardized challenge schema, clear “quote vs. commit” tool separation, receipt semantics, and safe retry expectations. Attendees will learn how to design predictable end‑to‑end flows where an agent encounters a “payment required” challenge, the user fulfills payment out‑of‑band, the host verifies an auditable receipt, and the agent resumes work.
"Isn't the whole point of MCP that every client behaves the same???"
That's the promise…until you run one server through five agent frameworks and watch the model receive five different things.
Schema fields vanish, descriptions get truncated, one server's single tool shows up as sixty-two in another, error semantics quietly change. The USB of agents, it turns out, ships with three different connectors.
Some of that is the MCP client. Much of it is the harness above it making its own calls about tool search, result retrieval, and context management. A client can be perfectly spec-compliant and still reshape what your tool looks like.
This talk separates those layers and makes the differences measurable, using real jobs-to-be-done that deliberately stress MCP capabilities like resources, progress, and structured output. (Dropping fields isn't always bad! But it should always be visible.)
You'll leave with a layered mental model for blaming the right layer, a jobs-to-be-done method for benchmarking client compliance, defensive patterns for tool authors, and mcp-mirror: an open-source diff tool plus a public, data-driven leaderboard.
Every agent starts simple: one model, one SDK, a demo that works. Then comes the second provider, the MCP tools, the fallback logic, the rate-limit backoff — and suddenly half your codebase is integration glue that has nothing to do with what your agent actually does.
Agent Router — newly donated to the Agentic AI Foundation, with a 1.0 GA release and production deployments at scale — collapses all of it into a single integration: every model, every tool, one declarative API.
We'll walk through a live agent workload end-to-end: routing across model providers with automatic failover; understanding exactly what each agent and team spends — and capping it before it surprises you; and choosing which MCP tools each agent can see and call. All declared in one place, none of it in your application code. You'll leave knowing exactly where a router fits in your agent stack, what it takes to run one in production, and how to get involved in the Agent Router project.
Semantic routing between LLMs often sacrifices data privacy by prioritizing context over sensitivity when balancing local and SaaS endpoints. For instance, a simple query like "What is Chris Nuland's salary?" can leak sensitive context to an external provider.
We introduce a reference architecture that elevates sensitivity as a primary routing metric, establishing a two-dimensional decision matrix with distinct enforcement paths: direct SaaS egress, redact-then-SaaS, and local-only isolation. Our system uses Microsoft Presidio with custom PII recognizers to pseudonymize sensitive entities (e.g., "Chris Nuland" becomes PERSON_1) before egress. Integrating NeMo Guardrails with vLLM-hosted small language models to form a secure egress point. Preventing unauthorized data leakage when managing shared context between models.
This session provides a demo of this stack, showing how platform engineers can enforce semantic routing with robust data isolation and redaction controls.
Agent skills, prompts, workflow instructions, and attached assets are quickly becoming things teams share, reuse, and depend on. But in many organizations, these are still copied around like helpful notes instead of treated like software that can break, drift, or create risk.
This session looks at what it means to build CI/CD for agent skills before rolling them out across an organization. We will cover practical ways to test whether a skill still works, run regression evals, check common failure modes, review tool permissions, test for prompt injection in skill files and assets, and safely roll out changes.
The goal is to move beyond “this prompt seemed to work for me” toward a disciplined engineering workflow for agent skills. Attendees will leave with a practical model for versioning, testing, validating, shipping, and improving agent skills so teams can adopt agentic workflows without creating compounding reliability or security problems.
You built an agent that's genuinely impressive: memory architecture, eval suite, harness, all dialed in. Then you try to ship it, and it stalls in review. The business needs guarantees: this action has to be authorized at runtime, this payment can only fire once, every change must be auditable, often to a regulatory standard. So you reach for what you have: more guardrails, tighter prompts, supervisor agents. The agent drifts from what made it worth building, and you still can't ship.
What you can't guardrail your way around: an agent can't own consequences. Agents are probabilistic by nature. This makes them powerful, and is why correctness can't live with them. Reducing agent capability won't give the business the safety it needs.
Seven Factors is an engineering methodology for another path: a deterministic layer that can own the consequences your agent never will. We'll walk through implementation patterns for authorization, idempotency, recovery, audit, more. You'll leave able to spot anti-patterns before building, and techniques to get capable agents to production, even under regulation.
Stop fighting your agents. Build the partner they've been missing instead.
Building ChatGPT Apps with MCP sounds straightforward—until you hit the real-world challenges: double iframes breaking your CSP, data sync issues between model and UI, mysterious HTML caching that defeats hot reload mobile testing that seems impossible…
At Alpic, we shipped multiple production ChatGPT Apps and distilled our hard-won lessons into Skybridge, a modern framework that accelerates MCP app development. In this talk, we'll share the practical patterns that actually work: managing widget state across the model-UI boundary, navigating Content Security Policy constraints, leveraging widgetParameters for tool visibility control, and handling multi-step conversations with intentional widget replacement strategies.
We'll cover concrete solutions including our dev server that solves OpenAI's HTML caching problem, how we enabled mobile testing, and why we added React hooks like `useCallTool` and Zustand-based store state management. Whether you're building your first ChatGPT App or scaling to production, you'll leave with actionable best practices you can apply immediately.
AI agents introduce a fundamentally different orchestration problem. Unlike traditional workflows, agents make decisions at runtime, interact with humans and external systems, and often execute over hours, days, or weeks. Durable execution is a necessary foundation – but durability alone is not enough.
As agents become responsible for increasingly important tasks, organizations need the ability to prove what happened, verify who or what performed an action, enforce policies and guardrails, and establish trust in execution outcomes. This requires a new set of capabilities that go beyond workflow orchestration, including identity-aware execution, cryptographic attestation, execution provenance, and verifiable audit trails.
In this talk, we'll explore the shift from workflow orchestration to agentic orchestration and the architectural patterns emerging to support it. Attendees will learn how durable execution, guardrails, and cryptographically verifiable execution histories work together to make autonomous systems reliable, governable, and trustworthy in production.
Swarm architectures matter when coordination itself is the hard problem. Central orchestration works well for decomposable tasks with clear authority, but it breaks down in open-ended coordination: multi-party negotiation, conflicting objectives, partial knowledge, dynamic membership, and cases where no single agent has enough context or authority to direct the work.
This session explores what it takes to support peer-to-peer coordination in open source agent systems. Using Mycelium, an open source project we have been working on, we will demo coordination primitives such as agent discovery, intent alignment, constraint negotiation, and shared state across a collectively evolving task.
This session will show where current collaboration features in OpenClaw-style agent systems fall short when agents need to coordinate as peers rather than simply exchange delegated tasks.
Attendees will come away with a clearer understanding of the coordination problems that arise in peer collaboration, practical approaches to address them, use cases where swarm is the right fit, and the infrastructure needed to support swarm patterns.
Most agent security starts with broad authority and chips away at it: pre-approved command lists, destructive-action warnings, trust tiers wrapping a shell. Claude Code is the most sophisticated public version of this subtractive model, and it is excellent engineering. The trouble is the model. You have to anticipate every dangerous thing an agent might do, and agents decide what they do at runtime.
An older idea from operating-systems security inverts it. Start the agent with zero authority and inject scoped capability objects. There is no policy to bypass, because authority that was never minted cannot be invoked. An agent cannot hallucinate past a capability it was never given.
We will trace what the additive model takes in practice: capabilities minted narrow, narrowed further when delegated, and gone after a single use. The lifecycle that grants authority is also the audit trail, which beats reconstructing which policy was active when something went wrong. You will leave able to tell whether your own agent starts from everything or from nothing.
Enterprise AI leaders and analysts now agree that data connectivity and context drive agent accuracy. Catalogs, semantic layers, and context repositories put meaning in a layer beside the data, and let the agent ask it. The question now has become: should this layer sit next to or within your AI gateway infrastructure?
A layer outside the request path can only be asked a question, and like a goldfish it forgets the question as soon as it routs it. A layer inside it sees and learns from the question, the data that came back, and whether the answer survived contact with the user. This breakout session explores the benefits and tradeoffs of this critical architectural decision, as well as the cross-system gateway capabilities that impact token spend, agent accuracy, and prompt latency across enterprise deployments.
See how Kong's unified API and AI platform takes agents from experiment to production: governing a real multi-agent system with A2A communication, MCP tool calls, and multi-provider LLM routing, all with end-to-end observability across the full data path.
What happens when your AI agent or MCP server goes down mid-task? What about when the API or database it depends on starts dropping connections? Your agent probably won't give up, because LLMs are persistent. But chances are high that it will redo everything over and over. Re-running tool calls, re-spending tokens, even for work that already finished. You'll still get your result, just slower, and at a higher cost.
In this live demo, we'll show what changes with Durable Execution. You'll join in the fun to become the chaos that breaks our demo. We'll watch the full execution path (Agent, MCP server, APIs and storage) while Temporal keeps resuming from where things left off, not starting over.
You'll walk away knowing how durable execution works in both agent code and MCP server code, how retries and replays prevent unnecessary rework and token spend when services fail and recover. Come see how "what if this other system goes down?" stops being a question you need to build custom handling for within your code.
A look at the future of agent authorization beyond coarse OAuth scopes. A live demo of agent intent governance and where nondeterminism belongs in authz.
Sutando is an open-source personal AI agent that runs on hardware its owner controls. It hears and speaks, sees the screen, handles mail and calendar, writes and reviews its own code, and keeps upgrading itself — one system doing all of it, for one person, continuously. It recently caught its own alerting pipeline dropping jobs silently and shipped the detector within the hour. Others now run their own, and the agents review each other's code — nobody asked them to. I'll bring
the live system and show where it has got to.
The Secure Agentic Framework (SAF) is an open-source, community-driven architecture for defending agentic AI. This hands-on workshop puts an AI skill in participants' hands: it scans a vulnerable reference environment, surfaces what is exploitable and why, and maps each finding to a concrete mitigation that attendees apply and re-scan to confirm it clears.
We cover SAF's two core implementations: SAF for MCP, securing the Model Context Protocol for AI tool integration, and SAF for k8s, hardening agentic runtimes in Kubernetes. Built on two years of adversarial research, the SAF for MCP matrix maps 65 attack techniques across 14 tactics, flagging threats like Tool Poisoning, Command Injection, and the MCP Rug Pull. Unlike high-level frameworks such as MITRE ATLAS, it offers the protocol-level specificity dynamic, tool-integrated agents require.
Attendees leave able to identify vulnerabilities in their own deployments, apply SAF controls, and contribute to this open-source framework.
MCP crossed 110 million SDK downloads a month, with well over ten thousand servers. The agentic ecosystem is scaling faster than almost anything open source has seen, and a surprising amount of what agents depend on in production runs on single maintainers and on reference servers that shipped as demos and quietly became infrastructure.
Open source has lived versions of this before: a single maintainer carrying a package with hundreds of thousands of weekly downloads, the cURL project pulling its bug bounty under a flood of AI-generated reports that overwhelmed a small volunteer team. Every dependency an agent relies on becomes a responsibility, and someone is carrying that load.
Agentic AI concentrates the social contract open source has always run on, because these dependencies now sit underneath software that acts on its own, calling tools and moving data. What used to be a hidden flaw is now one an agent will act on, at machine speed. We'll talk about supporting maintainers, making contribution the default, narrowing the gap between who consumes and who gives back, and staying responsible humans while the standards are still being shaped.
Point your coding agent, Claude Code, Codex, or open-source Pi, at a terabyte of files in a bucket and ask a question. It runs a model over everything: hours, real money. Every follow-up repeats the full cost, from zero.
Today's data agents run on the warehouse, where the hard part is already done: schema, lineage, and a semantic layer that says which data to trust. Most of your data has no warehouse. It sits on S3 as files, just bytes and paths, with no schema, no lineage, and no semantic layer.
So the agent builds that layer, and that is what makes it efficient. Its loop changes: before answering, it asks which layer is missing, builds it, then answers from it. Each pass leaves a typed, versioned, lineage-tracked dataset, so the layers compound. This is data modeling for unstructured data: what limits an agent is the structure you build, not the size of the model.
Those layers serve every agent, not just the one that built them. Expose them over MCP, datasets as resources and queries as tools, and they become shared, deterministic state. I show it live: one agent builds the result, a different client answers from it in seconds, recompute-versus-recall gaps in the millions.
Governance is what we want from agent systems: to know, and prove, what an agent did, what it was allowed to do, and what it could not. Most of the conversation about how to get there happens at the wrong layer: protocol design, permission prompts, system prompts. Those help. They are not enforcement.
What actually decides whether an agent reads your SSH keys is the OS. So, if governance is the goal, OS-level security is the mechanism, not a parallel track or a downstream concern, but the foundation.
This talk takes that seriously. We built Microsoft Execution Containers (MXC) because agents needed it: an open-source cross-plat policy runtime that decides, per tool invocation, what files, network, and processes are in scope. It composes with what each OS provides (bubblewrap, seatbelt, AppContainer) rather than replacing them, and lets one policy say something coherent across all three. We will cover where the thesis holds up, where platform primitives do not compose cleanly, and what is not yet solved by any of this, including the agent loop itself.
Production agent systems require this layer. The session is an invitation to shape what it should look like, together.
Million-token context windows promised to make agent-building easy: connect every tool, dump in every document, and let the model sort it out. In practice, the opposite happens. As an agent's context grows, performance degrades in surprising ways. And the failures get worse precisely in the situations agents live in: multi-step tool calls, accumulated history, and information pulled from sources that don't agree with each other.
This talk breaks down the ways long contexts fail using concrete, measured example.
Then we get practical, walking through tactics for fixing your context or preventing failures in the first place, with real results behind each.
Context is not free. Every token influences the response, for better or worse, and the job of the agent builder is deciding what earns its place.
We'll close with where this is all heading, why the most robust answer to context rot isn't hand-tuning prompts but treating context as something you assemble and compile programmatically, and what that looks like in practice.
What happens when an AI coding agent can interact directly with the devices its software runs on? This session shows how Device Connect enables AI agents to discover Arm-based devices, understand their capabilities, and build and deploy software across them. Using Raspberry Pi devices as a live example, we’ll explore how developers can extend agentic workflows beyond code generation to connect software, devices, and physical actions.
Most discussion of agentic commerce takes the platform's side. This talk takes the merchant's. I built ucp-probe — a minimal, unaffiliated agent, a few dozen lines, no platform deal — and pointed it at Allbirds' live commerce endpoints (UCP/ACP) in May 2026. The result is uncomfortable and clarifying. Reading a store's published capabilities at /.well-known/ucp is anonymous and permissionless. Querying the live catalog needs only self-identification — a small profile declaring the protocol version the agent speaks; one call returned a real product (Men's Wool Runner, $110, in stock) straight from the merchant's backend. But moving money is gated: a cryptographically signed agent (HTTP Message Signatures, RFC 9421) plus a retry-safe idempotency key. Reading is free; spending is not.
I'll run the probe live, then turn to what this means for anyone publishing a catalog: your data is already legible to any competent agent that asks, you can't gate the read, and you won't see most of it in analytics. The probe is open source; attendees leave able to run it against their own endpoints and reason about the one layer that's actually gated — the transaction.
Agents call tools. Logs tell you what happened, but they can't prove a record wasn't changed afterward. Once you run agents in production, that gap turns real during incident reviews, compliance checks, and disputes.
I built a tamper-evident approach and shipped it as an open-source TypeScript library (MIT, on npm). Every agent action becomes a record hashed with SHA-256 and chained to the one before it. Edit any field and the chain breaks.
Sealing a session produces a Merkle root, so you can verify a single action in O(log n) without replaying the whole run. I've run it against real production agent workflows and will demo verification catching a tampered record live.
Here's the open question I want to bring to this community: MCP standardizes how agents discover and call tools, but nothing in the protocol proves what an agent did. I'll show how this provenance pattern maps onto MCP tool calls, where a standard hook could live, and then hand it to the people building MCP to pressure-test.
Production agents now span multiple clouds by default. Flexera's 2026 State of the Cloud Report puts multi-cloud adoption at 89% of enterprises, and IDC projects a 1000x increase in agent token and API call loads for large enterprises by 2027. In practice this means a single agent workflow routes across managed inference from the hyperscalers (AWS, Azure, GCP, IBM, Oracle) and a dozen specialty GPU providers (CoreWeave, Lambda, Crusoe, Together, Fireworks), driven by GPU capacity limits and cost. Once a workflow crosses provider boundaries, it inherits every hard problem in distributed systems.
This talk treats multi-step agentic workflows as the distributed systems they are, and walks through four cross-cloud production patterns: durable execution for long-running workflows, idempotency for tool invocation under partial failure, cold-start absorption across providers and regions, and compensating transactions for workflow recovery. A seven-component decomposition of end-to-end latency, which maps directly to per-task cost, shows why fabric properties dominate model choice across cloud boundaries.
Patterns are vendor-neutral and reproducible from public benchmarks.
At FINRA, the move from AI assistants to agentic engineering required more than better prompts. It required custom agents with bounded responsibilities, MCP-based integration into enterprise SDLC tooling, and design patterns that keep humans in control while agents reduce repetitive engineering work.
This session shares how FINRA is building practical agentic workflows: guarded tool access, explicit context, observability, reusable skills, and MCP integration across repositories, CI/CD, and workflow systems. It will also discuss how an Agent Skills campaign, skills catalog, and enablement model helped turn experimentation into shared capability rather than one-off solutions.
Using SDLC use cases such as technology upgrades as examples, this talk will show what it takes to move from IDE-centric assistance to trusted, context-aware agents that are composable, observable, reusable, and fit for enterprise software delivery.
Most teams build an AI agent the way they'd regret building a service: one prompt doing seven jobs. Every requirement is another paragraph, every change risks regressing the rest, and the only unit of isolation is the whole agent. You can't prompt your way out of that shape.
The alternative, which we run in production for Grace, a senior-living advisor: stop writing agents – declare them. An AgentSpec is a small, versioned contract – one spec, one agent, one job. What it leaves out is the point. Provider, model, budget, and killswitch live on a per-agent gateway key, not in the spec; prompts live in a registry; tools are refs. That narrow waist buys three things by construction: governance (authority declared, enforced, and audited per agent), resilience (kill one key and exactly one agent stops; safety stays synchronous), and future-proofing (swap model or runtime with zero spec change). One spec is served over web, agent-to-agent, and as an MCP server – the platform itself becomes a tool any MCP client can call.
You'll leave with the contract, the gateway-as-policy-plane pattern, and an honest account of what's shipped versus still ahead.
Most developer documentation portals are still built for humans first. That worked when developers read the docs directly. It creates friction when they use AI agents and code assistants to solve implementation problems while coding.
Server log analysis of over 10 million requests on docs.adyen.com showed that 11.6% of traffic came from AI bots. 78% of generative AI traffic came from user-directed assistants pulling context for active coding tasks.
Developers are no longer only reading documentation. They are asking AI tools to interpret it, reason over it, and turn it into working code.
The problem is that standard web documentation isn't designed for this workflow. HTML pages and site hierarchies waste model context as bots crawl, guess, and reconstruct structure.
We addressed this by turning static docs into agent-ready markdown infrastructure.
We added /llms.txt for structured LLM discovery, exposed raw content through .md URLs, and packaged a full documentation mirror as a ZIP file.
This session shares how to move from human-centric HTML to machine-consumable markdown, reducing traversal overhead, avoiding unnecessary rate limits, and improving AI-generated integration code.
Agents can call APIs. They can't find and drive a physical device – yet.
The agentic stack stops at software. MCP and A2A let an agent invoke a tool; neither lets it discover and control a fleet of real hardware. Device Connect closes that last mile: an open, agent-native protocol for device discovery and network RPC over pluggable transports, plus a zero-infrastructure device-to-device mode that needs no broker and no cloud.
This is a working-code talk, not a roadmap. We'll walk the protocol: how a device advertises its capabilities, how an agent discovers it, and how an RPC call becomes an action on real hardware at millisecond scale – the right tier for fleet discovery and control. Then we go live: an agent takes a plain-English command, finds devices on the fleet, and moves them.
You'll leave knowing how to give your agents a body – discover, invoke, and orchestrate physical devices using the MCP-shaped mental model you already have, with open-source code you can run the same afternoon.
Coding agents can open a pull request in minutes. Whether that change is correct, traceable, and worth keeping is a different problem, and it is the one that decides whether an agent fleet is an asset or a liability in production.
This talk shares patterns from running a knowledge-graph-backed agent fleet in production, where humans and agents work on the same codebase, on the same timeline, against the same audit log.
Here are some examples of those patterns:
-Context as a bundle: assemble everything a task needs up front, instead of letting the agent retrieve chunk by chunk at query time.
-Provenance as working memory: an audit trail the agent reads to know what it did to understand why a decision was made.
-Code as truth: reconcile intent and reality
– Visibility as a query: treat throughput, context size, cost, and audit completeness.
A recurring theme: agents are a fast, honest mirror of your engineering culture. The same fleet, pointed at a healthy codebase and a brittle one, produces very different outcomes at identical speed. We close on where this connects to MCP, AGENTS.md, and the broader push toward structured, interoperable context.
Single prompts are yesterday's problem. Real agents live inside an agentic loop: plan → act → observe → update state → repeat. That loop is exactly where attacks hide, spread across turns, disguised as "reasonable" steps, and amplified by tools, skills, and memory.
Most current red teaming approaches ignore this structure. They treat agents like chatbots and probe them with individual prompts. In practice, the most damaging failures rarely appear in a single step. They emerge gradually as the attacker steers the loop across several turns.
In this talk we red team agents white box. Instead of blindly probing prompts, we model the internal structure of the agent and generate adversarial interaction trees that manipulate it across multiple turns.
The resulting exploits do not rely on a single malicious instruction. Individually reasonable actions accumulate into a compromise as the attacker bends the planning process, poisons memory, manipulates tool outputs, and chains safe operations into unsafe outcomes.
We'll demo several multi-turn exploit patterns, including memory poisoning, tool and skill output injection, planner steering & privilege escalation through chained tool calls.
The demo always works. Then you put real users on it and everything breaks. This talk is a brutally honest field report from six months of operating an AI agent built on Claude Agent SDK for a real human (me), handling real emails, real calendar conflicts, real mistakes, and real customer-service threads with Israeli print shops.
I'll cover the harness-level decisions that mattered most. Memory: why we abandoned vector DBs for a plain filesystem with markdown files, and how that unlocked auditability and cheap context. Scheduling: how script-gating — running a 30-second check before waking the agent — cut wake-up rates by ~80% and kept costs sane. Observability: the logging pattern that made multi-hour agent sessions debuggable. Resilience: how we handle MCP server disconnects mid-task without losing state. Cost: the before/after curve, and the single change that halved our bill.
This isn't a pitch for Anthropic or an SDK intro. It's the stuff I wish someone had told me before I started. No demo, no product — just production lessons.
AI agents have advanced fast, yet they still fail on real-world, long-horizon tasks. The hard question is why: the model, its tool use, the harness, or the task itself? To find out, we audited 6,000+ failed trajectories using both human labels and LLM judges, across 45 benchmarks spanning software engineering, reasoning, science, agentic tasks, data analytics, and multimodality. Three findings stand out.
First, harnesses shape failure modes. The top five categories account for 89% of errors, and the largest (endless loops and timeouts) accounts for 32%. Harness design can help agents verify and recover, or push them into loops and early stopping. Second, complexity does not always win. Model capability has the largest effect, but harness choice still matters: a simple general-purpose harness can outperform a model-specific one, showing the need for agent-harness co-design. Third, many tasks agents struggle with are not hard but broken, with environment bugs or grading where even correct solutions fail.
This session gives developers, researchers, and engineers a practical framework for diagnosing agent failures and improving agent evaluation pipelines.
