2026 Agenda

My father’s memories – and mine – became the memories of an AI companion.
As dementia made everyday connection harder, I built “Hello Dad”: a WhatsApp bot that used family photos, familiar stories, people, places, and small personal details to help bring memories back into conversation.
But the real challenge was not building the bot. It was understanding how to revive a memory in a way that felt useful and enjoyable, which stories were worth bringing up, how to phrase them gently, and how to tell whether the conversation was helping or causing confusion.
In this talk, I’ll share how I turned our shared memories into something the agent could use, what I learned from following the conversations, and how AI helped create a few more moments of recognition and connection with my father.

Data retrieval is already one of the most valuable capabilities that agentic systems bring to enterprises. Healthcare is no exception — efficient search of clinical data is a central challenge of healthcare AI, since clinical reasoning depends on accurate retrieval from huge volumes of patient data.
But clinical data is also the kind of data engineers hate: schemaless, deeply temporal, inconsistent, and constantly changing. And that’s even before the accuracy and privacy requirements that healthcare demands. How do you get an agent to retrieve reliably from that?
That was the challenge behind ALICE, a medical chart agent now in daily use by clinicians to answer clinical questions, support diagnostic decisions, and surface risks. In this talk I’ll walk through Alice’s agentic retrieval core, its data architecture, the problems we had to solve, and the design decisions that made efficient retrieval possible in a demanding, real-world medical environment.

Security detections are only as useful as their freshness. For years, many detection pipelines treated rules as SQL queries over historical data: powerful, flexible, and easy to reason about, but fundamentally batch-oriented, creating a delay between suspicious activity and actionable signal.

At Cato, we moved this workload into real-time stream processing. The challenge was evaluating thousands of detection rules continuously without adding proportional overhead to every event. Instead of asking “does this rule match this event?” 500 times, the engine asks “which rules match the values already present in this event?”. As a result we just run one query instead of 500.

We will cover moving from batch SQL scans over S3 to streaming rule evaluation, preserving throughput stable as rule count grows. We will also share benchmark results comparing this approach to traditional rule libraries and show what it takes to make real-time detection practical at production scale.

Everyone’s building AI agents. Almost nobody’s running them on live data. The typical architecture is a complex and fragile distributed system that must maintain consistency between all its pieces – Kafka consumer, LangChain, vector DB, scheduler, retry logic. Every part is a consistency gap.

What if the agent WAS the stream processor? No Kafka-to-LangChain-to-VectorDB plumbing. No retry logic. No consistency gaps between detection and action. State, checkpoints, exactly-once tool execution – all inherited, not bolted on.

This talk covers the patterns: hybrid rules + LLM reasoning, durable execution that survives crashes, and per-entity memory across events. All live, using Apache Flink Agents – a new open-source framework, which is part of the apache flink ecosystem – with demos spanning detection, investigation, and autonomous action.

Production LLM systems fail politely. Every call returns 200, every JSON parses, and the
wrong answer sails straight through.

Engineering instincts were trained on deterministic code: a passing test means it works,
a green dashboard means it’s healthy, a retry means a second chance. Put an LLM, or a
fleet of agents, in the loop and none of that holds. Part of your system is now
stochastic, and it fails in ways your stack was never built to notice.

This is a 101 for engineers who aren’t data scientists: which habits break, and what
replaces them. Contracts that pin data better, acceptance by statistics, not a
single green run, and alerts that fire on significance.

You’ll leave knowing how to better reason about the part of your system that depends on the prompt, the temperature, and apparently the phase of the moon.

This talk is about engineering synthetic data to hit all three: realistic, complex, and diverse. I’ll walk through grounding it in real distributions, deliberately injecting the mess and edge cases real systems produce, and expanding coverage into the long tail on purpose instead of by accident. Then the loop that makes it compound: as new failures surface in production, they feed back into your synthetic scenarios — so your agent keeps getting tested against a harder, broader world and keeps getting better over time.

A new model drops every week. A new agent framework claims to change everything every day. A new term is trending on Twitter and you’re not sure what it is. If you’ve ever closed fifty “must-read” AI tabs without reading one, you know the feeling. FOMO.
Five years inside an AI research lab building foundation models, teaching, speaking, and staying elbow-deep in the ecosystem the whole time, taught me the FOMO doesn’t go away with seniority. It goes away when you stop optimizing for coverage. One rule, five minutes: the filter I use to decide what’s actually worth my attention this week, and permission to ignore the rest.

When integrating LLMs into data pipelines and analytics products, we often make one critical mistake: we talk to the model like it is a human colleague. We use vague instructions, rely on negative constraints, and assume the model understands our context. But LLMs do not read between the lines; they are mathematical prediction engines where the exact phrasing we choose literally dictates the probability distribution of their output.
In this 5-minute lightning talk, we will explore the tangible impact of language mechanics on LLM performance. We will dive into five highly actionable, structural language tweaks that data practitioners can use to drastically improve LLM reliability in production.

Every major football tournament comes with the same office tradition: the prediction pool. Overnight, everyone becomes a football expert. Why bother following the sport all year when you can ask an LLM to predict every match five minutes before the deadline? What could possibly go wrong?

“What’s offside?” you ask. Great question! I have absolutely no idea. So I did what any reasonable engineer would do: I asked an LLM to help me predict every match. The result was obvious: I absolutely dominated… the bottom of the leaderboard.

Then I realized I was asking the wrong questions. I stopped treating the LLM like an oracle and started treating it like a researcher.

And the results were…. Marvelous!

This talk presents a multi-agent system that detects, diagnoses, and self healing data incidents and the architecture choices that made it trustworthy in production. The core principle: deterministic orchestration on the outside, LLM reasoning on the inside. Agents reason over lineage and metadata graphs instead of guessing, propose fixes inside an isolated sandbox, and are gated by validation contracts set up front, so a “fixer” can’t heal a pipeline by deleting the failing test. Every production-impacting action stays human-approved and reversible.
The verdicts are grounded in live data, not just metadata: agents run checks inside the client’s secured sandbox, querying the warehouse and calling source product database data with production credentials, to compare against ground truth. Credentials and data never leave the client boundary. I’ll cover the detect → diagnose →heal topology, where to draw the autonomy line, the failure modes we hit, and a customer incident resolved e2e.

Getting online-database feel from cold S3 storage — sounds too good to be true. It isn’t.
Cold data doesn’t need to live in expensive online databases. But keeping it accessible within an online latency budget after moving it to a data lake? Harder than expected.
This is the story of removing abstractions one by one — the SQL engine, the query planner, the file reader, the network layer — until what remained was fast enough and cheap enough. Each layer we stripped revealed how data lake formats actually work, and unlocked another 300ms of latency at a fraction of the cost.
You’ll leave with a clear mental model of what’s inside a data lake file format, where managed solutions hit their limits, and a practical approach for the next latency problem that off-the-shelf tooling can’t solve.

Sorting is an integral part of a data engineer’s pipeline, yet it is often overlooked. In this talk we will take a look at a production bottleneck: a multi-PiB workload that required us to scale more sorters than writers. We will take a deep dive into adapting classic External Merge Sort to our use case. By using a multi-layered optimization approach we will fit the algorithm to our compute resources by leveraging the CPU cache and multiple cores, and to our data by exploiting the non-uniform distribution.

Most AI agents today suffer from digital amnesia: they forget conversations, lose context between sessions, and treat every interaction as if meeting you for the first time. We explore how knowledge graphs can serve as persistent, temporally-aware memory systems for AI agents, moving beyond static vector embeddings to dynamic, relationship-rich storage that evolves with each interaction. This content piece covers practical implementation patterns for building graph-based agent memory, comparing direct database integration with tool-based approaches through popular frameworks. You’ll learn how to extract entities from conversations, model temporal relationships, and implement cross-session continuity that makes agents truly conversational partners rather than stateless responders.

For years, the line was clear: Apache Flink owned ultra-low-latency, event-driven processing while Apache Spark dominated high-throughput streaming. Spark 4.0 redraws this line. Real-Time Mode brings continuous low-latency processing to Structured Streaming, and the new transformWithState API delivers the flexible state management that event-driven systems demand.
In this session, we will dive into a technical discussion of both Spark and Apache Flink, exploring Spark’s transformWithState and RTM alongside Flink’s mature event-time engine.

As the two engines converge, we’ll examine what still sets them apart under the hood, in execution pipelines, in state backends, and in architectural philosophy, and, just as importantly, where those differences no longer matter in practice.

Whether you’re optimizing a pipeline, upgrading to Spark 4.0, or architecting a greenfield platform to serve AI agents, you’ll leave with clear criteria for choosing the right engine.

Apache Iceberg won the open table format war, then AI changed what we want from our storage. Vector search, embeddings, and random-access training pipelines fight the scan-oriented architecture Iceberg was built on. This talk examines where Iceberg structurally struggles, benchmarks it against LanceDB on AI-shaped workloads, and maps the emerging landscape: AI-native formats, hybrid architectures, and vector-capable query engines. So if you thought the format wars were over, think again – the AI round is just getting started.

AI agents are transforming how we work with data, but they still struggle when they lack context about which tables to use, what the data means, and how it is commonly queried. At Wix, a project that started as cataloging our trusted gold-layer tables became a production metadata ecosystem that supports data discovery, BI tools, and now AI agents.

In this session, we’ll share how we automated metadata creation with AI: creating table and column descriptions for about 900 gold-layer tables, building glossary definitions and mappings that improved agent results by 40%, and creating sample queries based on common usage patterns. We’ll show how this context helps agents break down business questions, find the right tables, and move from question to usable query faster, with practical lessons for teams that want to make their own data catalogs AI-ready without endless manual documentation.