Abstract

Embedding models for retrieval have long been treated as black boxes. That has started to change. A young research field at the intersection of mechanistic interpretability and information retrieval has begun opening retrievers up, and the findings quickly turn into capabilities: embeddings that unfold into interpretable latent terms, so you can actually read why a document matched; sparse features usable as an indexing vocabulary in their own right; and relevance signals you can locate and steer, changing what a retriever favours without retraining it. This talk is a tour of these findings and what they make possible in practice, including what the same lens reveals about classic failure modes such as hub documents and collapsing multi-intent queries.

Bio

Alper Nebi Kanlı is a Staff Software Engineer (AI Search) at Optimizely in London, where he builds search and retrieval systems. He has spent a decade working on search, AI engineering, and machine learning in production. He writes about language models at alpernebikanli.com, time to time speaks at London AI meetups including PyData London, and co-organizes the AI Signals meetup.

Abstract

Most LLM-in-healthcare talks come from one side or the other: either the clinical side, which tends to stay conceptual, or the engineering side, which tends to treat "clinical context" as a footnote rather than a design constraint. I sit across both — as a registered nurse and clinical advisor with extensive hands-on experience, and as a product developer who now builds and architects these systems directly. That combination is rare, and as a woman working in a space that's still heavily engineering-dominated, it's a perspective I don't think gets enough airtime either. It's exactly what lets a talk like this go deep on the technical side without losing what actually makes these systems safe or dangerous in a real ward.

Bio

Martina Wyss is an LLM and Healthcare AI Specialist working at the intersection of large language models, medicine, and digital health. With hands-on expertise in training, evaluating, and fine-tuning LLMs—specializing in prompt engineering and Reinforcement Learning from Human Feedback (RLHF)—she focuses on building safe, clinical-grade AI applications. Combining her technical LLM focus with a background as a registered nurse (Dipl. Pflegefachfrau HF) and a degree in human-centred design from the University of the Arts London, Martina bridges the gap between AI engineers, clinical workflows, and patient needs to ensure healthcare LLMs are accurate, reliable, and practical for real-world deployment.

Abstract

Prompt engineering has evolved from simple input crafting into a core architectural discipline for building reliable AI systems and agent-based applications. However, most implementations fail when they move from experimentation to production due to lack of structure, evaluation, and system-level design. In this talk, we explore prompt engineering as an architectural layer within modern AI systems, focusing on how to design prompts that are maintainable, observable, and scalable in real-world applications. We will cover: How prompt engineering fits into end-to-end AI system architecture Designing structured prompts for AI agents and tool-using systems Prompt lifecycle management: versioning, testing, and evaluation Failure modes: hallucination, prompt injection, and unstable outputs Meta-prompting patterns for dynamic and adaptive systems How solution architects should design prompt pipelines in production environments By the end of this session, attendees will understand how to move from ad-hoc prompt writing to systematic prompt engineering as part of a production architecture for AI agents and LLM-based systems.

Bio

Solution Architect specializing in designing scalable cloud and AI-driven systems. Focused on bridging application architecture with emerging AI agent technologies, including prompt engineering, orchestration layers, and production deployment of LLM-based systems.

Abstract

In machine learning, we often evaluate models against an established ground truth, treating the resulting metrics as evidence of how well a model performs. But what happens when the ground truth itself depends on assumptions, competing definitions, or scientific objectives that aren't necessarily black and white? I've been exploring this problem through independent research into atmospheric blocking — large-scale atmospheric patterns associated with prolonged heatwaves and other extreme weather events. Despite decades of scientific study, there is no single universally accepted definition of atmospheric blocking. Established detection methods can disagree about whether an event occurred, when it began, or how long it lasted. This raises a question that goes beyond the reliability of training labels: before deciding whether a model is right or wrong, shouldn't we first establish what we're actually trying to achieve? A model trained to reproduce an established blocking detection method might achieve excellent accuracy against its reference labels. But does that mean it has learned something scientifically meaningful? Would a different definition be more useful for understanding extreme weather? And how can we design experiments that challenge our assumptions rather than simply reinforce them? In this talk, I'll use atmospheric blocking as a case study to explore how scientific objectives, assumptions and definitions shape the way we train and evaluate AI systems. We'll examine why apparently contradictory labels can both be defensible, how evaluation metrics can reward the wrong behaviour, and how to build validation frameworks that help us test whether our underlying assumptions are actually useful. Although the examples come from climate science, the implications extend to LLMs, AI agents and automated scientific discovery, where success is often subjective, multidimensional or difficult to measure. The challenge isn't always determining which answer is correct. Sometimes it's recognising that we've been asking the wrong question.

Bio

Veronika Ulanova is a Senior Software Engineer at PhysicsX, where she has led engineering initiatives focused on turning complex AI and machine learning capabilities into scalable, customer-facing products. Her work spans technical leadership, software architecture and the development of reusable platforms that bridge the gap between ML capabilities and production applications. Alongside her professional work, she independently develops research originating from her MSci project, applying deep learning to detect atmospheric blocking - large-scale weather patterns associated with prolonged heatwaves and other extreme weather events. Her interests lie at the intersection of scientific AI, climate science and software engineering, particularly the challenges of model evaluation, scientific uncertainty and reproducibility.

Abstract

An agent wrote a change. It passed review, it passed CI, and then it took a production path down for about three hours. Nothing in the diff was wrong on its own, which is exactly why it got through, and the failure only existed in the combination of the edits. I have been shipping AI-generated code to production since I was fourteen, and this incident changed how I work more than anything else has. It took far longer to diagnose than an equivalent bug I would have written myself, and the reason was not the code. It was that I could not ask the author what they had intended, and none of the reasoning behind the change existed anywhere. Commit message, pull request, ticket: nothing. This talk is that incident, and then the three checks I have run ever since. Keeping a change small enough that reverting it is genuinely one step, rather than a careful unwind at three in the morning. Actually testing that the revert works instead of assuming it will. And moving the policy check to before an action executes rather than alerting after it has already landed. I will be honest about what each one costs in shipping speed, because none of them are free. Tool-agnostic, no live demo, nothing to install. If you are handing more of your pipeline to agents this quarter, this is the failure mode I wish someone had described to me first.

Bio

Artemis Leonardou is a software engineer and DevRel at NOFire AI. She has been building since she was 14 and now ships AI-generated code to production as a matter of routine, which is where most of what she talks about comes from. She was selected among the top 2000 global CS talents for Y Combinator's AI Startup School, has won first place in three hackathons, and her technical content has crossed 2 million views as Artemis Codes. She has spoken at React Summit and TechBiz, speaks at DevConf.US in September 2026, and leads a hands-on workshop at Open Conf in November. She is 19 and still a full-time student.

Abstract

Parametric flood insurance pays without a claim. A satellite confirms water above a stated depth and the money moves. Organisations are buying it now for informal settlements across Africa and Asia, and the trigger has a gap. Standard Sentinel-1 thresholding over eight documented floods in dense neighbourhoods detects none of them, because side-looking radar over packed low-rise building never sees the ground, and turbid water sits close to dry concrete in backscatter. The instrument is blind where the policy is sold. This session closes that gap with an agent, and spends most of its time on the design work that makes such an agent safe to point at money. We'll go end to end. How a spoken report in a low-resource language becomes a calibrated measurement. How it is priced, so one report is worth a measured quantity with a ceiling set by your own model's skill. How evidence accumulates until a zone crosses the payout line. Then the constraints. A toolset with no capability to broadcast a public warning. Repeat reports from one handset adding no weight. Evals that catch the agent leading a witness. A payout computed in deterministic code a loss adjuster can rerun a year later and reproduce exactly. You'll leave with the shape of all of it, and an honest account of where it is still weak.

Bio

Kayode Adeniyi is an AI Research Engineer. With years building flood models using computer vision methods and satellite technology across Africa, and a background writing production payment infrastructure in Nigeria. He has delivered AI ecosystem assessments across Africa and Latin America for the United Nations Development Programme, won the Luminance AI Challenge at Cambridge Judge Business School, and presented on auditable AI at the Palace of Westminster.

Abstract

Most eval advice assumes you can check the answer. But a lot of high-stakes LLM work has no definitive answer- like qualitative coding, thematic analysis, narrative findings. These are outputs where two expert humans will legitimately disagree, and where "correct" is a judgement rather than a match. In UK government social research, those outputs feed policy decisions, so "the model seemed confident" is not an acceptable standard of proof. This talk covers how we've approached validation in that environment: separating the parts of a pipeline that do have ground truth from the parts that never will, building statistical validation harnesses for the former, and designing human-in-the-loop review that catches failure in the latter. I'll cover what we measure, what we deliberately don't automate, and the failure modes we've hit. Attendees will leave with a practical framework for deciding which parts of a subjective pipeline can be evaluated algorithmically, which need human judgement by design, and how to defend either choice to a sceptical client.

Bio

Oliver Gooding is AI & Automation Lead at IFF Research, a UK social research agency working for central government clients including DWP, the Home Office and HMRC. He built and leads IFF's AI strategy and governance framework, and has spent the last two years shipping production LLM tooling into government research projects, from automated figure checking to LLM-assisted content analysis. He has a background in social research methodology and an MSci in Physics from Bristol.

Abstract

Prompting a frontier LLM to flag bias in news works well in a demo. In production, with articles arriving continuously from publishers and social media, the cost, latency and inconsistency soon become a problem. This talk describes how we built a system that classifies around 70 types of bias (from framing and omission to loaded language and ideological slant) and rewrites stories to be balanced. We began with LLM prompts, used their outputs plus human review to build a large, politically balanced dataset of news stories, and trained an in-house model that replaced most of the API calls.

You'll see how we designed the taxonomy, how we kept the dataset balanced, where prompting still beats the small model, and the human-in-the-loop checks that stop "debiasing" from turning into censorship. I'll also cover how we measured cost, latency and agreement with human reviewers before and after the switch.

Key takeaways

1. A practical path from prompt prototype to labelled dataset to an owned model
2. Designing and balancing a multi-label bias taxonomy
3. Where to keep humans in the loop, and how to measure fairness

Bio

Abdul Aleem Khan is a UK-based software engineer and technical co-founder who has been building production AI systems since 2018: computer vision running on edge devices in retail stores, and real-time news pipelines that detect and rewrite biased and toxic content. As co-founder and CTO of two AI startups he built and led engineering and AI teams, designed microservice and edge architectures, and created proprietary datasets where public ones did not exist. Products he built have been recognised by national and Asia-Pacific technology awards, and he was selected for Google for Startups' first AI Academy APAC.

Abstract

Large language models appear remarkably capable in isolation until they meet the systems the business actually runs on: ERP, ITSM, HR and procurement platforms with decades of customisation, undocumented integrations and hard-won internal standards. The bottleneck is rarely the model; it is context, data quality and governance. In this talk, I will walk through practical patterns for giving agents a reliable map of an organisation's systems, processes and dependencies; making instances and data "AI-ready" before agents touch them, and keeping humans in the loop with approval gates, standards checks and documentation trail, whether a person or an agent made it. We’ll explore what it takes to move from agents that can call enterprise tools to agents that can safely reason about and act within complex enterprise environments.

Bio

Zoe Yan is a founding AI engineer at Echelon AI, where she builds AI agents for long-horizon enterprise workflows and automation, serving some of the world’s largest enterprises. Previously, she worked at Porsche Digital on large-scale AI systems, multi-agent workflows, and emerging deep-tech applications in the automotive industry. Her background combines applied research with hands-on engineering across LLMs, agentic systems, and real-world AI applications. She is also active in the AI community as a speaker, hackathon mentor and judge, and helps build and grow AI communities.

Abstract

Agent evaluation is often reduced to a final-answer score or an LLM-as-a-judge prompt. For real agentic systems, that is rarely enough. This talk presents a layered approach to evaluating agents across outcome correctness, environment state, trajectory quality, tool-use behavior, latency and cost, repeated-run reliability, and evaluator quality. It also looks at where deterministic checks work, where model-based judging is useful, and how trace-level evaluation can be combined with human calibration.

Bio

Tahreem Rasul is a Google Developer Expert in Generative AI and an AI/software engineer specializing in production GenAI systems, including agentic workflows, RAG, evaluation, and cloud-native AI applications. She regularly speaks at developer conferences and technical communities on practical AI engineering, with a particular interest in reliability, context engineering, retrieval, and evaluating agentic systems.

Abstract

18 months after LLM4S kicked off, and one year after Kannupriya Kalra and Rory Graves showed a usable version on the Scala Days Switzerland stage, LLM4S has matured into a production-ready platform. In this talk, we’ll share the journey to LLM4S 1.0, from an ambitious idea for bringing first-class generative AI capabilities to Scala and JVM to a complete platform for building production AI applications. We’ll explore what worked, what failed, what we learned from building in one of the fastest-moving areas of technology, and why Scala’s type system and functional programming foundations have proved particularly valuable in the age of LLMs and agents. Along the way, we’ll demonstrate how LLM4S has evolved to support capabilities including multi-provider LLM integration, tool calling, MCP, agent orchestration, memory, observability, streaming, speech and multimodal AI, and production deployment patterns. Expect live demos, architecture diagrams, lessons from the open-source journey, and a practical look at what it takes to move from an AI experiment to a production-ready Scala application. Whether you have followed LLM4S from the beginning or are discovering it for the first time, you’ll leave with a clear picture of what LLM4S 1.0 can do, where the ecosystem is heading, and why your next AI project can be built in Scala.

Bio

Kannupriya Kalra is the Co-Founder of the LLM4S Foundation and creator of LLM4S, an AI-native platform for Scala. She is an engineering leader based in London. She contributes to the AI and Scala open-source ecosystem through the Scala Center and Google Open Source and has led Google Summer of Code programmes for the Scala Center in 2024 and 2025. She is also collaborating with Manning Publishing in New York to create practical AI learning resources for developers. A global speaker, Kannupriya has presented on AI, Scala, and open source in more than ten countries. She is passionate about empowering developers through hands-on generative AI projects, open-source contributions, and responsible AI education. Her engineering experience includes building scalable backend systems using functional Scala at Sky in London. Rory Graves has been passionate about coding for as long as he can remember, starting with writing games in BASIC many years ago. Over a 30+ year career, he has worked across a vast range of systems, from embedded software to distributed, internet-scale bidding engines. His experience spans industries, company sizes, from two-person startups to multinational corporations, and programming paradigms. A long-time advocate of Scala, Rory has contributed to numerous open-source projects, including performance optimisations in the Scala compiler. Today, he works in a hybrid role supporting applied AI and ML research while continuing to mentor developers and share knowledge through public speaking. Outside software, Rory is a martial artist, a windmill tour guide, and a passionate mentor of programming and public speaking.

Abstract

A customer-service agent can give a convincing answer and still take the wrong action. Once agents can call tools, change records or pass work between agents, evaluating the final response alone is not enough. Using a published multi-agent customer-service reference implementation, this session will explore how to test what an agent does as well as what it says. We’ll walk through scenarios involving incorrect tool selection, missing information, failed actions and situations that require a human handoff. For each, we’ll examine what to check with deterministic tests, where model-based evaluation can help, and where human judgement remains necessary. Attendees will leave with a practical approach to building scenario-based evaluations and a reusable release checklist for deciding whether an agent is ready for a controlled pilot. The examples will use AWS services, while the evaluation principles apply across platforms.

Bio

Olushola Oladipupo is an Enterprise Solutions Architect at Amazon Web Services, supporting customers across the UK and Ireland. He builds and publishes practical examples of generative AI and multi-agent systems, with a focus on evaluation, human oversight and enterprise adoption. He has spoken at AWS re:Invent, AWS Summits and AWS Community Day West Africa. His work connects technical architecture with the decisions teams need to make to adopt AI responsibly and effectively.

Abstract

Generalist RAG systems fail in high-stakes domains like finance. They can't handle the intricate cross-references and conditional logic of regulatory text, leading to hallucinations and making them untrustworthy. In this talk, I will share our practical journey building a domain-specific AI for regulatory compliance. We'll cover:
1. Architecture Evolution: Moving from standard vector RAG to a Graph RAG architecture that uses a regulatory ontology to understand relationships, not just retrieve text.

1. SLM Advantage: How combining Graph RAG with specialized Small Language Models (SLMs) yields higher accuracy, 80x lower cost, and drastically improved output stability compared to generalist LLMs .
2. Ensuring Reliability: A framework for synthetic data generation, benchmarking, and continuous evaluation to make inherently probabilistic AI systems auditable and reliable for production. We will include a practical architecture walkthrough and a live demo of our approach.

Bio

Karthigeyan R J is the Founder of Comply2Reg, building domain-specific AI for banks and financial institutes in the regulatory and compliance space. He formerly worked as a GenAI Solution Expert at 4CRisk.ai (acquired by CUBE, UK - market leader in RegTech) and has hands-on experience fine-tuning models and building agentic workflows for regulated environments.

Abstract

This talk presents an automated regression testing framework designed to validate the migration of a virtual assistant from a rule-based, session-oriented conversational platform to a modern, LLM-driven orchestration platform. The framework replays multi-turn conversations against both systems in parallel and produces a side-by-side comparison of response quality, latency, and fallback behaviour, scored using two complementary text similarity metrics: Jaccard similarity for lexical overlap, and cosine similarity over sentence embeddings for semantic equivalence. A three-phase test runner coordinates live conversation capture, automated input replay, and a consolidated metrics report covering per-turn detail and unanswered-question coverage. The project was developed with the assistance of an AI-powered coding agent. The work establishes a repeatable, evidence-based process for verifying conversational parity and identifying gaps before full production cutover.

Bio

Peter Fox is a mid-level Software Client Engineer in IBM Client Engineering's Financial Services squad in London, where he has spent over five years building client-facing AI pilots using the garage methodology - working across AI agents, generative AI and LLMs, AI governance, database access management, and computer vision. Each engagement typically runs for two to three weeks with a multi-disciplinary team, tackling some of the most complex business challenges faced by enterprise clients in financial services and beyond. Before specialising in AI engineering he held roles in technical AI sales - supporting higher education and life sciences clients and contributing to a sign language recognition app built on deep learning - and in cybersecurity with a focus on SOAR platforms. A proficient Python developer and professional mentor with science teaching and outreach experience at both secondary school and university level, Peter holds a PhD from Imperial College London in theoretical physics and brings strong analytical and problem solving depth to every team he works in.

Abstract

Long before language models, we had AI systems that found clever ways to satisfy exactly what we asked for but not what we meant. An AI playing Tetris learned to pause the game before it lost, so it technically never lost. We laughed at the time, but the alignment problem behind it was never solved, and agents now have far more capabilities than just pausing a game. This talk is about what happens when an agent follows the request against the intent of its user: where that behaviour comes from, what it means for security, and which mitigations actually exist today.

Bio

Guilherme Santos is an ethical hacker and co-founder and CEO of Blindsight, a Zurich-based AI security company. A former Fortune 500 red teamer and zero-day hunter, he now works on adversarial attacks against AI systems and agents, including prompt injection, data poisoning and agent misuse. He is Global Ambassador for Germany at the Global Council for Responsible AI and is a regular speaker at GITEX, IT-SA, ShmooCon, and many more.

Abstract

7,000 emails sent to 50 people :-( It was my agent, working for my business, doing exactly what it had been allowed to do, and frankly asked to do. This talk is an honest account of running a real business on a team of AI agents: the mass email, agents reporting work "done" when it wasn't, and agents that made up an answer when a tool failed instead of saying so. For each failure I'll show the engineering control that now stops it: permissions removed so the agent can't do it at all, checks that compare the agent's claim with the evidence, and humans placed exactly where judgement matters. You'll leave with a practical pattern for building agents you can actually trust in production, and deliver real value to your business.

Bio

Mark Weston is an AI engineer and the founder of FireHorse Associates, where he designs and runs governed systems of AI agents that do real work inside regulated businesses. He trained as an electronic and electrical engineer at Loughborough and spent more than 30 years in financial services technology. That included a decade at HSBC as CIO for Regulatory Technology, Chief Data Officer for Trade Data and CIO for Financial Crime Risk Operations, where he brought machine learning into anti-money-laundering work across 40 countries. He went on to co-found Regulativ AI, a cyber RegTech platform. Today he builds production AI agents for his own businesses and for clients, and teaches senior leaders to build their own. His view, learned the hard way, is that what matters is how you control the agents, not how many you have.

Abstract

AI agents have gone from finishing your sentences to running commands, reading results, and trying again. In this talk, Viktor shares practical insights from two perspectives: managing a large mobile codebase at scale and building personal side projects (a game, an audio app, a home server via Telegram). Key takeaways & topics covered: - Single-instruction pattern: Write instructions once and reuse them across all tools (Claude Code, Cursor, Xcode's agent, local models) without vendor lock-in. - Autonomy boundaries: Clear guidelines on what agents may do unasked vs. what requires approval. - Failure logs: Recording past failures so agents stop suggesting ineffective fixes. - Real-world split: An honest evaluation of what agents genuinely do alone today versus where human engineering remains essential.

Bio

I am a Senior iOS Engineer with over 8 years of experience building high-scale, resilient mobile applications. Currently, I ship product experiments for inDrive's Intercity module, serving millions of users globally. My work focuses on complex mobile architecture, developer experience (DevEx), AI-assisted development workflows (including MCP servers and agentic tooling), and native system integrations. I am an active tech speaker, technical writer, and mentor.

Abstract

AI systems are now writing hypotheses, designing experiments, and analysing results across genomics, materials science, and climate modelling, with systems like Google's Co-Scientist and ERA already published in Nature this year. But the same speed that makes these systems exciting is quietly eroding one of science's core guarantees: that a result can be checked and reproduced. This talk looks at the actual failure modes showing up in AI-driven research pipelines today, from hallucinated citations and silent data misalignment to evaluation setups that reward confident answers over correct ones, and connects them to the rigorous uncertainty quantification practices long used in fields like neuroimaging, where a single noisy scan can wreck an analysis if untreated. I'll walk through concrete techniques for building evaluation and QC layers around AI-assisted scientific pipelines, so speed doesn't come at the cost of trust. Short bio: Data Scientist with 9+ years of experience developing signal processing and machine learning methods for biological and medical imaging time series data. Currently, I focus on how LLM models and the latest AI agents can accelerate scientific progress. Holds a PhD in Neuroscience and patents for software and methods in neuroimaging analysis.

Bio

Egor Levchenko is a Machine Learning Engineer at all.health and holds a PhD in Computational Neuroscience from UCL, where he built NNDb-3T+, an open multimodal neuroimaging dataset published in Scientific Data. He previously spent three years at Neurometry developing game-based digital biomarkers for cognitive health, worked as a data scientist at Sberbank, and co-founded a neuromarketing startup. His work sits at the intersection of neuroscience, data science and applied AI, with a focus on turning complex signals into practical models.

Abstract

Welcome to the Museum of Engineering and Artificial Intelligence. Lead time and deployment frequency occupy the first cabinet. Keep walking: prompt chains, context-window bragging and tokens-per-second leaderboards have their own exhibits. Eventually, even today's LLMs are behind glass. Drawing on my book, A Brief History of Engineering… and What Comes Next, and my work with GitLab, this technical thought experiment follows the signals shaping AI: inference economics, generation architectures, reliable autonomy and models gaining tools that act. We examine cost and latency at a stated quality threshold, task completion, retries and human intervention. Autoregressive and diffusion language models provide a concrete example of how changing the machinery changes what we should measure. Then we extrapolate. What happens when agents coordinate at machine speed and action outruns verification? A worked scenario connects those questions to evaluations, tracing, orchestration, sandboxes and enforceable limits. The final exhibit imagines today's autoregressive LLMs outdone by “quantum diffusers”. This explicitly speculative future asks what must survive technological change, leading to Intentware: my proposed next-generation architecture for preserving purpose, constraints and accountability. Attendees leave with signals to watch and engineering questions to apply to their own AI systems.

Bio

Neil Douek is a platform engineering practitioner, speaker and author of A Brief History of Engineering… and What Comes Next. His experience spans developer experience, DevSecOps and automation in financial services and global technology organisations, including LSEG and Fujitsu. He works with enterprise engineering teams through GitLab Professional Services and OTTRA. A Team Topologies Advocate and certified GitLab Solution Architect, Neil explores how AI changes the tools, measurements and responsibilities of software engineering.

Abstract

How do you train an enterprise search agent without access to a real company’s private data? We built a synthetic company instead: employees, projects, emails, Slack conversations, documents, and calendars—all inside a stateful environment with a clock that prevents the agent from seeing the future. This talk follows our attempt to train a 4B model to search that world and produce accurate, cited daily briefs. I’ll walk through constructing verifiable tasks, designing leakage-resistant evaluations, and a counterintuitive failure: on-policy distillation drove task completion toward zero even as the training loss improved. We recovered by building a stronger starting policy through off-policy distillation, then using reinforcement learning to repair reliability. On our held-out synthetic benchmark, the final model retained 91.1% of the frontier baseline’s failure-adjusted F1 and completed 92% of episodes. You’ll leave with practical lessons for building synthetic agent environments, measuring search quality separately from completion, and debugging post-training when a better loss produces a worse agent.

Bio

Nick is co-founder and CTO of Whitney AI, making model training accessible to AI engineers without a research background. Previously at Microsoft, he post-trained on top of frontier models like GPT-4 and GPT-5 as an ML engineer in the early days of the Azure X OpenAI partnership, often before public release. He later led engineering for Azure's RL-as-a-serving offering and served as a post-training tech lead in Microsoft's Superintelligence division. His work spans evaluation design, practical post-training, and why owning your own intelligence matters in an economy increasingly shaped by a handful of labs.

Abstract

A short expression can contain a powerful idea. A short prompt can produce an entire application. How do the tools we use change what we can think and build? Drawing on experience at Morgan Stanley, Accelex and Carta, Phillip Mortimer traces the evolution of document intelligence from regular expressions to agents that check and revise their own work. Connecting programming notation with AI-assisted mathematics, he explores how to express what matters, delegate the details, and work creatively with systems that contribute ideas of their own.

Bio

Phillip Mortimer specialises in document intelligence and AI. Previously CTO and Chief Scientist at Accelex and Senior Staff Machine Learning Engineer at Carta, he also spent a decade as a quantitative developer at Morgan Stanley in London and Tokyo. He is a visiting lecturer in MLOps and LLMOps at Université Paris Dauphine-PSL. Outside work, he can often be found in the dojo training for his next kickboxing belt.

Abstract

Prompt engineering is shifting from human-authored instructions to agent-driven execution. Recursive language models treat prompts as inspectable objects, enabling dynamic workflows where structure emerges at runtime. In multi-agent systems, agents generate briefs, delegate tasks, spawn peers and craft subsequent prompts. This talk introduces recursive prompt engineering linking recursive models, dynamic workloads and automatic agent spawning to show how recursion evolves from loops to full agents. It examines delegation, spawning, verification, boundaries and stop conditions when humans no longer write every turn. Attendees gain a practical model for goal- and constraint-led systems where agents decompose and continue work safely.

Bio

Founder of Superagentic AI. Building tools and frameworks for better Agent Experience.

Abstract

Language learning is fundamentally about decomposing communicative intent into teachable components. But what if we could use LLMs not just to teach, but to understand what learners actually know, and automatically generate personalised learning paths from that understanding? This talk takes you behind the scenes of a large-scale knowledge graph project that uses carefully engineered prompts to extract granular learning objectives from content, map their dependencies, infer learner mastery from free-form production, and generate bespoke learning pathways. In 30 minutes, we'll cover: - What a Knowledge Graph is (and why does an EdTech company like Busuu need one?) - How we tagged our extensive course library - How we map connections between separate knowledge components - How we measure learners' abilities from both course exercises and free-form production - How we create bespoke Learning Pathways Prompts in EdTech are not just for content generation. The most valuable prompts in this pipeline are ones that teach LLMs to reason like domain experts (linguists, educators, assessment specialists), not ones that ask them to produce content.

Bio

Hannah originally joined Busuu in 2019 as an education expert creating English learning content, but as the product as developed she now oversees the development of AI features across languages. She leads a team of Computational Linguists and Learning Designers who work collaboratively with Busuu's product team and AI engineers to develop prompts for features to support language learners in their journey.

Abstract

Prompts are becoming a critical part of production software. They are becoming the backbone of critical product flow. In our case, a 5% rollout of a prompt and model configuration silently remained in production for 5 months. The incident demonstrated that prompts have become production code, and they can benefit from production level engineering practices. We need a reliable way to answer basic questions such as Which prompt version is running? Who approved this change? What changed? Was it evaluated? Can we safely roll it back? In this talk, I'll introduce the concept of Prompt Release Engineering and share the architecture behind an internal platform we're building for prompt management. We'll explore how prompt versioning, diffs, audit trails, review workflows, evaluations against golden datasets, production observability, and instant rollbacks can come together to create a safe and scalable prompt lifecycle. Beyond the technical architecture, I'll discuss the patterns that emerged from building systems where non-engineers can safely prompt multiple times a day without sacrificing reliability, governance, or compliance. Attendees will leave with a practical blueprint for release engineering around prompts to enable faster iteration while improving reliability, governance, and trust.

Bio

Ritesh is a Senior Staff Engineer at Wise Payments Limited, where he leads the Generative AI and Automated Data Governance functions. His role focuses on identifying the most critical business challenges and driving organizational change to eliminate them at the root. He brings extensive experience building and scaling complex products, including privacy platforms for Meta, monetization systems for Omio, ML-based network security solutions, and low-latency, high-scale advertisement bidding platforms.

Abstract

As prompt engineering becomes embedded in real production pipelines, one of the most overlooked challenges isn't writing better prompts, it's knowing what "better" even means when the output needs to serve a creative vision. This talk looks at prompting from the other side of the table: not as a researcher or engineer, but as an Art Director using AI tools daily to support a live game (Beat Saber) with a distinct visual identity. I'll share how creative teams build internal prompting workflows and templates to keep AI-generated output aligned with narrative tone, emotional consistency, and brand identity at scale, and why the same prompt that produces a "good" image can produce a wrong one the moment context, taste, or creative judgement isn't built into the process. I'll also touch on where this breaks down: prompting alone can't encode style consistency or creative intent, and what that means for teams trying to template or scale creative prompting in production. This is a practitioner's view from inside a creative production pipeline, useful for anyone building prompting systems that need to serve subjective, brand-sensitive, or creative outcomes, not just technically correct ones.

Bio

Art director for the most successful and innovative VR game in the history of the medium. Master of Architecture bringing structure to aesthetics to various industries from animation and exhibition design to game development. Working on the bleeding edge of AI development as a creative. Driving the revenue of the Music Packs for Beat Saber - visual design is the first hook for the buyer.

Abstract

Post-training models for a specific task is a common way to reach state-of-the-art performance within a narrower domain with an open-source model. So, you want to post-train your own 3 trillion parameter model. What do you need to know? You might think that the approach for post-training any model is basically the same; or at the very least follows the same patterns, and, therefore, there is nothing unique about the 3 trillion-parameter scale. While true in part, this misses a bunch of nuance. There are some unique problems that arise only at larger scales or custom architectures. This is true on an engineering level as much as on a scientific modeling level. I will be using Kimi-K3 as our modeling example (likely an unsurprising choice for those familiar with the field) and go through the things that are useful to know if you're entering this scale. The assumption is that you have working knowledge of the field. Feel free to ping me if you have any questions.

Bio

Paulius holds a PhD in Machine Learning from the University of Cambridge, where he developed work on self-healing machine learning, deep hierarchical learning, and deployment-time controled methods. Currently, Paulius is a founding research scientist at Cursive. In a previous life, Paulius was working in management consulting, banking, and data analytics.

Abstract

The AI industry is obsessed with autonomy. Agents that plan, reason, delegate and dynamically decide what to do next are increasingly presented as the future of enterprise AI. But what if the most reliable AI systems are deliberately less autonomous? This session challenges the assumption that greater autonomy produces better enterprise outcomes. We'll explore why human-designed workflows, independently tested agents, explicit orchestration and organisational context may provide a more practical foundation for production AI than unrestricted agent collaboration. Through an engineering lens, we'll examine where deterministic control should end, where probabilistic reasoning genuinely adds value, and how to build AI systems that are both intelligent and accountable.

Bio

Harrison Kirby is the Co-Founder and Chief Technology & AI Officer of Great Wave AI, specialising in enterprise AI architecture, agentic systems and the engineering of reliable, production-ready AI platforms. With over 15 years of experience in engineering, enterprise technology and technical leadership, Harrison is a leading voice in the practical application of artificial intelligence. He is the author of Exploring GenAIOps and Reliability Is The Product: Engineering AI Systems People Can Depend On. An early pioneer of Retrieval-Augmented Generation (RAG) and agentic AI in the UK, Harrison focuses on bridging cutting-edge AI innovation with secure, scalable and dependable enterprise deployment, championing engineering excellence, governance and trust in AI systems.

Abstract

Abstract

Before your first container hits production on Kubernetes you install a distro, a CNI, an ingress, cert-manager, Prometheus, Grafana, Loki, ArgoCD and Harbor. None of them is your app. 57% of Kubernetes users run more than 11 separate components, the control plane is a pet that needs restoring from backup at 3am, and "why can't A talk to B?" sends you through DNS, Endpoints, kube-proxy, iptables, CNI logs and NetworkPolicy.

I have been evaluating, running and being paged for Kubernetes since 1.0 in late 2015, and I kept notes. This year I stopped complaining and built the thing: Reliaburger, a container orchestrator in Rust that ships scheduling, gossip membership, Raft, eBPF service discovery, ingress, mTLS, an image registry, metrics, logs, GitOps and chaos testing in one binary, driven by TOML. An app with health checks, ingress and autoscaling is twelve lines. There is no overlay network, no CNI and no kube-proxy: a name, a virtual IP and about 390 lines of C in the kernel.

The talk covers the four scars and what Reliaburger does about each: apps instead of pods, a control plane that is elected rather than installed, SWIM gossip on one slide, and one connection from web to redis step by step. It also covers what it cost to build with Claude and Codex (200 hours and about a thousand pounds for roughly 220k lines of Rust), the rules that kept the models from doubling the codebase every week, the design we got wrong, and what Reliaburger deliberately does not do. Then a live demo, if the demo gods allow.

It is 0.2.0, free and Apache 2.0. Download it, break it, tell me.

Bio

Miko Pawlikowski has been running platform teams on top of Kubernetes since version 1.0, and has the scars to show for it. He is the author of Chaos Engineering (Manning) and of Reliaburger, a batteries-included container orchestrator written in Rust, along with the book Building Reliaburger that documents how every subsystem was designed and built.