AGNTCon + MCPCon Europe 2026

Agent harnesses. MCP. Skills. MCP Apps. If you've been watching the AI space and feeling like everyone else already understands something you don't, this talk is for you.

I've spent the last several months building with each layer of the modern AI stack, and what I kept finding was that the concepts aren't as hard as the terminology makes them sound. Nobody had just sat down and explained what each piece actually is, what problem it solves, and how they fit together. So that's this talk. Technical enough to be useful, grounded in real workflow experience, and paced so that by the end you have a clear mental model of where AI tooling actually stands today and where you fit in it.

This presentation highlights general rules that any engineer should keep in mind before implementing an AI agent, around one core idea: legislation should be treated as part of the system architecture. At EU level, the AI Act is the central regulation, but adjacent European legislation may also be activated based on the AI agent’s actions.
Translating legal obligations into technical requirements from the design stage makes deployment safer and more compliant. Five practical takeaways help in doing that:
1. compliance should not be seen as a one-time check, but as a continuous monitoring and evaluation process
2. it demands interdisciplinary work from the design phase, not a back-and-forth decision chain
3. the agent is a system, not a legal person, so the ones held accountable are the humans behind it
4. a clear map of what the agent does, accesses, and produces is what lets you navigate the law
5. there is no universal rule applicable: start with the AI Act, then identify the adjacent legislation activated by the agent’s specific functions
The goal is to design agents that are safe, compliant and genuinely useful, by treating law as an architectural concern, not bureaucracy.

The next phase of agents is not one human supervising one model. It is multi-human, multi-agent work across teams, tools, and trust boundaries. The decisive moments are not model outputs; they are human approvals, edits, overrides, escalations, and handoffs, and the rationale behind them. Today those moments leak into chat logs, tickets, and application code, where they cannot be replayed or audited.

CHAP, the Collaborative Human-Agent Protocol, gives this shared workspace a protocol layer. A small Core (workspaces, participants, tasks, artefacts, and an append-only evidence log) carries composable profiles for review, structured override, operating modes, handoff, deliberation, identity, and signed audit. It composes with MCP and A2A rather than replacing them: MCP connects agents to tools, A2A connects agents to agents, CHAP lets humans and agents do accountable work together.

The talk covers the protocol gap, the Core primitives, a worked 'override as evidence' flow, and lessons from building the open reference implementations and conformance harness. Spec, code, and examples are public.

Paper: https://arxiv.org/abs/2606.09751
Repo: https://github.com/BrightbeamAI/chap

Agent systems are getting more capable, but they are still hard to operate when a single user request fans out across multiple agents, tools, model calls, queues, and outbound messages. In this session, we will walk through how we built an open observability plugin for OpenClaw (InsightClaw) that turns that opaque execution path into a connected telemetry story using OpenTelemetry.

The talk covers a practical design that combines three signal paths: typed lifecycle hooks for request, agent, tool, and response flow; diagnostics events for model usage, cost, queue, webhook, and stuck-session signals; and optional provider SDK auto-instrumentation for GenAI calls. Together, these produce connected traces, useful operational metrics, and cross-session lineage for handoffs, spawned subagents, and parallel branches.

We will show the trace model we used, the session semantics we had to define for real workflows, and the engineering tradeoffs around payload capture, runtime patching, and correlating control-plane events with agent execution.

A2A Protocol v1.0 is the first stable, production-ready release of the open standard for agent-to-agent communication — marking the transition from a protocol you could experiment with to a foundation organisations can commit to with confidence.

This talk is delivered by two maintainers who helped shape the release. We cover what changed from v0.3 and why: the deliberate choice to prioritise maturity over reinvention, new enterprise capabilities — signed Agent Cards, multi-tenancy, modern OAuth flows, and a web-aligned architecture — and the breaking changes that were unavoidable on the path to a durable standard.

We also cover the SDK story: how official SDKs support v1.0 while maintaining backward compatibility with v0.3, and a per-interface versioning strategy that makes progressive migration practical rather than a forced cutover.

Finally, we look at extensibility: how extensions add capabilities while keeping a stable core, and how custom protocol bindings let implementations replace the default transport while preserving A2A semantics.

If you are building on A2A today or evaluating it, this talk gives you a clear picture of what changed, why, and how to migrate.

You don't write a pile of glue code to onboard a new hire — you give them an account and point them at a few channels. So why do we hardcode workflows and wire up orchestration SDKs to put AI agents to work?

There's a lighter path: let agents coordinate the way people already do — by tagging each other and posting into channels — so the system is something you own and shape rather than something you engineer. This talk makes the case for that low-code, team-owned approach, the patterns that make it work, and the surprising amount of custom infrastructure it lets you delete.

We hand coding agents our workspace, our keys, and a shell, then walk away while they run code generated at runtime from untrusted input: files in the repo, docs fetched off the web, output from MCP servers nobody audited. The obvious fix is isolation: give every agent its own kernel. So we start there, running Claude Code, Codex, and others inside sub-second, hardware-isolated microVMs (libkrun/KVM), where even root in the guest is stuck behind the hypervisor's MMU boundary, not just a shared-kernel namespace.

But isolation on its own isn't enough. An isolated agent can still read the .env beside your code, exfiltrate it, wreck your workspace, or abuse a tool you never vetted. So we add defenses, live, one layer at a time: copy-on-write workspace snapshots with a per-file review gate, non-overridable secret exclusions, a DNS-aware egress firewall, a hardened Wolfi guest (custom Go PID 1, dropped capabilities, seccomp, no-new-privs), and an MCP proxy with Cedar authorization profiles. We finish on the attack surface most tools forget: the security tool's own config.

It's all Apache-2.0. The lesson carries to any agent you run: isolation is the floor, not the ceiling.

Every major agent orchestration framework today conflates task execution with the control layer that should govern authority and policy. This talk argues for a cross-domain agent control plane: a runtime layer external to the agent that performs authority checks and policy enforcement at defined boundaries, independent of the agent’s internal logic. Grounded in inter-domain routing, it proposes a semantic model built on five invariants: domain boundary as the control unit, boundary-crossing capability classes as the permission unit, scope-narrowing delegation with bounded elevation, unbroken provenance to a registered trust anchor, and boundary enforcement without inspecting internal behavior or payload content. The model introduces two runtime artifacts: the Agent Control Envelope (ACE) for authorization and the Agent Activity Envelope (AAE) for behavioral constraint. Attendees will leave with a precise mental model, two concrete artifacts, and a clear argument for why agent interoperability needs explicit boundary semantics before wire formats harden around the wrong primitives.

The agent ecosystem is converging on a common way to discover skills, making it easier for agents to find and load domain-specific knowledge. But discovery only solves the first problem.

Once skills become part of production workflows, they need to evolve. Instructions change, best practices improve, and capabilities grow. Without a way to version and manage those changes, agents risk relying on outdated or incompatible knowledge.

In this talk, I’ll explore lessons learned from publishing and distributing skills at scale, discuss the emerging standards around skill discovery, and propose a framework for skill versioning, compatibility, and evolution. If skills are becoming the package ecosystem for agents, it’s time to start thinking about dependency management too

Building multi-agent systems for production remains challenging, not only due to integration complexity, but because validating that systems behave as intended is still largely unsystematic. Teams hand-wire LLMs, tools, and memory, add observability late, and lack clear ways to ensure agent interactions remain reliable and aligned as systems evolve.

This session introduces MAS-Lab, an open, spec-driven framework that makes agent systems composable and verifiable. It extends the integration discipline of protocols like MCP and A2A to all components -- models, tools, memory, messaging, governance, and observability -- through declarative specifications. The result is systematic integration, built-in observability, and reusable best practices.

During the session, we demonstrate a multi-agent trip planner and show how a single spec enables teams to compose agents, apply governance controls such as budgets and guardrails without modifying logic, and validate behavior by exploring alternative designs through reproducible experiments.

Attendees will leave with practical patterns to ensure agent systems behave predictably, remain aligned with intent, and can be trusted in production.