OSS + ELC EU 2026

Development teams are seeing a rapid increase in code contributions, many of them from AI tools and pair-programming copilots. As AI-generated code increases, human reviewers can quickly get overwhelmed.

The instinct to throw "an AI reviewer" at the problem mostly doesn't work. A single agent produces shallow comments, misses context, and either over-flags or under-flags depending on how it's prompted.

This talk presents a pattern that works better, built and demonstrated from scratch: three specialized reviewing agents in parallel, followed by a developer agent that applies the fixes. One reviewer focuses on architecture, one on security, one on test coverage. When all three finish, a fourth agent rewrites the code to address each issue and opens a new PR for human sign-off.

The architecture is adaptable: teams with data sovereignty requirements can swap the hosted model for a self-hosted open-weight alternative (Llama 3, Mistral) served via vLLM or Ollama.

Attendees leave with a concrete, working pattern they can adapt to their own projects, and a clearer picture of where AI can genuinely reduce review bottlenecks.

Includes live demo.

It's hard to experiment, let alone develop applications, for LLMs when access to GPUs is restricted. But what if you could do your development on CPUs? This session demonstrates how to deploy vLLM on a local Kubernetes cluster using Kind and Podman Desktop, running entirely on a CPU-only laptop.

The presentation covers building a minimal environment, deploying vLLM containers, and running inference against models like Gemma-3 and Qwen2.5. A live benchmark comparison between vLLM and llama.cpp reveals when each runtime excels across different model sizes and hardware profiles. The session then extends the workflow to production-grade serving with KServe, including autoscaling and model lifecycle management.

Attendees will learn how to deploy and test vLLM locally without GPUs or cloud resources, understand when to choose vLLM versus llama.cpp based on model size and hardware, and extend a local setup to production-grade serving with KServe.

Silent failures in MCP tool invocation aren't random. They trace back to a single root cause: tool descriptions that are too vague for agents to reliably select the right tool.
A SAIL Research study of 856 tools across 103 MCP servers found 97% have at least one quality defect, 56% fail to clearly state what the tool does, and 89% provide no guidance on when not to use it. A second study of 10,831 servers confirmed that well-written descriptions get selected 260% more often, improving task success rates by ~6 points.
Working with the Glama founder, I developed TDQS (Tool Definition Quality Score) : an open-source framework scoring MCP tools across six dimensions: Purpose Clarity, Usage Guidelines, Behavioral Transparency, Parameter Semantics, Conciseness, and Contextual Completeness.
This talk covers how TDQS was built, what scoring thousands of real-world servers revealed, and how the open-source community can adopt it as a quality standard for MCP tool authorship.

Running LLMs near devices or in constrained edge environments changes the observability problem. A small model can answer successfully while still being unusable: first token arrives too late, prompts burn scarce CPU/RAM budget, output is malformed, or gateway/model-selection errors hide behind green Linux and container metrics.

This session walks through a reproducible, CPU-first Ubuntu demo for resource-constrained self-hosted LLMs. It uses small Ollama models (llama3.2:1b and qwen3.5:2b) on the same CPU workload with MicroK8s, Juju, COS Lite, Tempo, a FastAPI OpenAI-compatible gateway, and Canonical's Charmed OpenTelemetry Collector. The gateway emits OpenTelemetry GenAI spans, metrics, and trace-correlated logs; Prometheus, Loki, Tempo, Grafana, and Alertmanager turn them into an LLM golden-signals view.

Using recorded normal, slow, expensive, error, and low-quality scenarios, attendees will see how time-to-first-token, token usage, traces, alerts, and quality signals reveal whether a local model is useful within tight compute constraints. The model comparison shows why embedded and edge AI decisions need measured latency/cost/quality trade-offs, not just 'the model runs.'

We had a problem: every new integration meant writing the same code twice—once for our React dashboard, once for our AI assistant. JIRA, TestRail, Jenkins, GitHub—the duplication was unsustainable.

MCP changed everything. In this lightning talk, I'll show how we built 7 MCP servers that now power both our dashboard AND our AI agents from a single source of truth. 50+ tools, used daily by Dev, QE, and Management teams.

In 5 minutes, you'll see:

- The architecture: FastAPI as a unified backend → MCP Servers → External APIs (JIRA, TestRail, Jenkins, GitHub, GSheets, Release Calendar, Risk Predictor)
- The pattern: Thin MCP tools that call centralized APIs—one integration, two consumers
- Real metrics: 10+ hours/week saved per engineer; release tracking, regression monitoring, and production health checks unified.
- Why MCP wins: AI agents and dashboards evolve independently while sharing the same data layer.

We eliminated duplicate code, reduced maintenance burden, and shipped faster. All code is open source.

This talk could prevent the next big data breach.

Building enterprise-ready AI poses challenges around data security, scalability, and integration, especially in compliance-regulated industries. We're already seeing security breaches with AI Agents in the news. This is a complex problem - Imagine having N users, M Agents and O actions. How do you design permissions around that?

This session will cover how modern permissions systems can ensure AI Agents have access only to authorized data. The talk will look at why the Google Zanzibar model of authorization which uses Relationship-Based Access Control (ReBAC) is well suited for fine-grained authorization at scale. The talk covers the nuts and bolts of how a Google Zanzibar system works under the hood, and how to apply it to AI Agents with techniques such as pre-filteration and post-filteration.

The talk will also include a live code demo implementing authorization for AI Agents + RAG using Open Source tools such as Weaviate, Langchain, and SpiceDB.

Vibe coding is now the norm, and more open-source code is AI-generated. But is it secure?

We present the Agent Security League, an open leaderboard built on SusVibes (200 real-world tasks, 108 OSS projects, 77 CWEs). Unlike benchmarks frontier labs cite to showcase progress, SusVibes evaluates what developers actually use: a harness coupled with an LLM, not the model alone. Across 15+ combinations — GPT-5.5, Gemini 3.5, Fable 5 — with agents like Cursor and Claude Code, functional correctness can exceed 80%, yet our best fair security score is 29%.

This means ~7/10 working AI patches leave the bug open.

Strikingly, even models (e.g., Fable 5) that lead model-only benchmarks score no better on security once wrapped in a real agent.

Agents also cheat: early on they reverse-engineered fixes from git history, inflating scores up to 42×. Our 3-layer pipeline—prompt hardening, workspace sanitization, LLM-based anti-cheating eval—nearly killed that, but memorization of upstream fixes from training data persists.

We show cheating examples, share fair results, what actually improves security, and argue anti-cheating and contamination controls must be standard for agentic benchmarks.

Agentic AI systems are rapidly evolving from research experiments into production workloads. However, while building a proof-of-concept agent can take only a few hours, building a reliable, scalable, and observable agentic platform remains a significant challenge.

This session explores how modern open source technologies can be combined to build production-ready agentic systems on Kubernetes. We will walk through a complete architecture that includes large language models, agent orchestration, retrieval systems, tool execution, memory management, observability, and infrastructure automation.

Using technologies such as Kubernetes, Kubeflow, LangGraph, Model Context Protocol (MCP), vector databases, and open-source serving frameworks, we will demonstrate how to move from a simple agent prototype to a resilient platform capable of supporting enterprise-scale workloads.