Giselle van Dongen

Giselle van Dongen works on the reliability of distributed software, from benchmarking stream-processing engines to explaining how AI agents recover from failures and remain usable over long-running tasks. In her reliable-agent-stack presentation, where she is credited with a Restate affiliation, she demonstrates durable execution: recording a program’s progress so it can resume after an interruption, preserve session state, and wait for human decisions.

Benchmarking stream-processing reliability

Her earlier work combined real-time analytics with distributed-systems research. She worked as a lead data scientist at Klarrio, specializing in real-time data analysis, processing, and visualization, and researched and taught distributed processing at Ghent University. She completed her doctorate in 2021 with Open Stream Processing Benchmark, an analysis of distributed stream-processing frameworks.

With Dirk Van den Poel, she studied Spark Streaming, Spark Structured Streaming, Apache Flink, and Kafka Streams. Their fault-recovery experiments deliberately failed masters, workers, drivers, applications, and tasks, then measured downtime, recovery, data loss, and duplicate processing. They distinguished a system’s return to service from its ability to catch up on accumulated work and examined how delivery guarantees affected performance. Their related research also investigated what determines whether adding machines makes a streaming job scale.

Durable applications and recovery at each step

Her Restate work applies these reliability concerns to application development. In December 2023, she co-authored the Java SDK announcement with Stephan Ewen and Pavel Tcholakov, introducing durable services and workflows to JVM developers, including a Kotlin API with coroutine support. With Nik Nasr and Igal Shilman, she also explained how Restate’s interface helps developers inspect blocked executions, follow calls across services, and manage deployed services. These contributions address both how distributed applications run and how engineers understand them when work stalls.

For AI agents, van Dongen emphasizes the software operations surrounding the reasoning loop: model calls, tool calls, conversation updates, approvals, and communication between workers. Her Pydantic AI integration guide combines typed agent definitions with recoverable execution, persistent conversations, and multi-agent coordination.

A central distinction in her critique of checkpointing is recovery at the individual step. Saving an agent’s state periodically can leave completed actions between checkpoints unaccounted for. If a tool calls an API, sends an email, and writes to a database, restarting the entire tool after the email has been sent can repeat that action. She favors recording individual operations and their results so recovery can reuse completed steps. Failure detection and retry schedules must also survive the process they supervise.

Research agents that wait, recover, and accept direction

Her resilient research-agent example makes these mechanisms concrete. Connected to Slack, the agent proposes a research plan, waits for approval, launches parallel researchers, and assembles a report. In the demonstration, a failed web search is retried using the execution journal to preserve earlier progress. Restate runs as a separate server in front of the agent service; the SDK sends execution events to that server, which records them for recovery. A durable promise records an outstanding approval, allowing the function to suspend until the response arrives and survive intervening restarts or redeployments. On serverless infrastructure, the suspended function does not consume execution time while waiting.

Van Dongen also demonstrates persistent, steerable agents. A user can add context while research is underway instead of waiting for a finished report. A session controller uses an LLM to decide whether the new message belongs to the current investigation or requires a new task. “Focus on frontier models” supplies context to the existing run; switching to AI-policy research cancels the ongoing work and starts another investigation. Cancellation propagates through the call chain to subordinate agents.

This interaction depends on consistent session state. Her examples use session-keyed virtual objects, which act as stateful entities with their own identifiers, stored conversation history, and durable handlers. Serializing updates within a session prevents two messages arriving close together from launching competing writers that overwrite the same history, while separate sessions can proceed concurrently.

Versioning and shared model controls

• Immutable deployments: Long-lived execution also creates a versioning problem. With Francesco Guardiani, van Dongen explains why agents need immutable deployments through a fraud tool whose scoring scale changes from 0–10 to 0–100. A historical score of eight can change meaning if an execution resumes under new tool descriptions. They advocate pinning each execution to its starting version, including prompts, schemas, tools, and model configuration, and treating any move to another version as a deliberate operational decision.
• Shared LLM gateway: Her research-agent project further separates model calls into a shared LLM gateway, applying a model allow-list and department-scoped concurrency limits. In the talk, she explains how moving an inline model call into its own handler lets multiple agents share policy checks and flow control as cost or access requirements change. This illustrates the flexibility she seeks in agent infrastructure: developers should be able to extend an application while retaining recovery guarantees across its components.