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.

LLM-powered “agents” are quickly becoming the default architectural pattern for AI-enabled systems.

Need automation? Agent.
Need integration? Agent.
Need reasoning? Agent.

But agents are not an upgrade; they are a trade-off. They introduce non-determinism, larger attack surfaces, evaluation complexity, and operational unpredictability.

In this session, we’ll examine three common architectural patterns for LLM-enabled systems:
- Deterministic workflows (state machines, orchestrated pipelines)
- Service-oriented architectures with LLM augmentation
- Fully agentic orchestration with dynamic tool use

Rather than comparing features, we’ll analyze these patterns across real engineering constraints:
- Failure isolation and blast radius
- Latency and cost predictability
- Observability and debugging complexity
- Security boundaries and permission scoping
- Evaluation and regression testing strategy
- Operational burden over time

This talk offers a practical decision framework grounded in system design principles. You’ll leave with a mental model and checklist to evaluate whether an agent is justified, or whether a simpler architecture will deliver more predictable, resilient outcomes.

The AI coding conversation has been almost entirely about greenfield: new features, fresh repos, throwaway scripts. Meanwhile the codebases that quietly run hospitals, factories, and banks are maintained by skeleton crews drowning in tribal knowledge, dead build systems, and 20-year-old decisions. Single-LLM code assistants do not survive contact with them.
Agentic systems can, but only with very different workflow patterns than the ones usually demoed. This session is a field report from modernizing a long-lived industrial codebase: what worked, what catastrophically did not, and the patterns that emerged.
We cover the shift from "LLM completes my code" to "agents reason about my codebase": the two-loop research and execute split, vertical slicing, measurement-first execution, structured unknowns, and rollback discipline. We name the failure modes that wreck naive setups on legacy code, including context overflow, hallucinated APIs, false-positive fixes, and agentic drift, and the practices that prevent them.
It closes with where agents still lose, what OSS tooling is missing, and how the community can treat legacy maintenance as a first-class agentic AI problem.

Most software companies are experimenting with AI, yet many struggle to move beyond isolated chat interactions and proof-of-concepts.

This session presents a practical case study of how a traditional software development organization with little prior AI experience adopted agentic engineering practices within 90 days. Guided by an engineer with hands-on experience in AI agents, MCP, RAG systems, and AI-native development workflows, the organization moved from sporadic experimentation to productive use of agentic systems in everyday engineering work.

Attendees will learn how high-value use cases were identified, how MCP-based tools, agent skills, and RAG-powered knowledge systems were introduced, and how trust in agent-driven workflows was established across development teams.

Not every experiment succeeded. Some assumptions proved wrong, some tools disappointed, and several approaches had to be reworked. This session shares the lessons learned, the mistakes made, and the strategies that ultimately accelerated adoption.

The result was a measurable shift from AI curiosity to AI-enabled engineering, establishing the foundations for long-term AI-native development.

We promised our CX team an agent that would write customer success plans. Six months and four architectures later, we shipped a compiler that calls LLMs in four places.

Each architecture was the right fix for the previous one's failure. The single skill could not enforce quality. The subagents drifted across stages. The scripted prompts hit determinism walls. Only when we accepted that "agentic" was the wrong frame did the output become reviewable, replay-able, and trustworthy enough to ship to real customers.

The talk is a tour of the architectural moments where we learned what LLM-driven systems can and cannot own. Specific failures: a real customer plan shipped with the wrong rows, a quality firewall the LLM kept violating until we made it structural, and "temperature=0" arriving as a footnote rather than a solution.

You leave with three things. A maturity curve from skill to engine. A working distinction between pipeline work and agent work. And a vocabulary for the conversation with stakeholders who keep asking when the agent will be ready, when what they actually want is a compiler with an agentic UI.

Every agent framework reinvents context management differently: scratchpads, artifacts, or memory stores. This creates distinct storage problems (system config, user memory, thread scratch, task state, shared workspaces, external data, and inter-agent messaging) collapsed under "agent context", with no shared vocabulary and a lack of interoperability.

In an attempt to close this gap for the industry at large, we present a production architecture that models agent context as scoped virtual filesystems. Agents interact through standard filesystem tool calls (read, write, and list), while the agentic AI platform enforces scope, lifecycle, and access control per mount.

The talk covers three layers. First, scoped state: how four filesystem scopes (system, user, thread, and task) compose across collaborating agents, using file modes and mount isolation to prevent cross-scope leakage. Second, external data as mountpoints: turning retrieval into navigable directory trees with ls/cd/cat semantics instead of opaque vector search. Third, protocol implications: how this maps to the MCP spec today and the case for filesystem operations as a first-class agent interoperability primitive.