Elliot Gunton shows how Hera lets Python developers define Argo Workflows without maintaining large YAML files.
2
Qian Li explains how DBOS durable workflows checkpoint inputs and outputs in PostgreSQL so AI jobs can resume after failures.
3
Alan Nichol argues that customer-facing agents need stateful process calling for business logic that spans several conversation turns.
Summary
This mini summit brings together three approaches to making AI systems easier to run when failures, delays, and changing inputs are unavoidable. Elliot Gunton presents Hera, a Python SDK that translates Python workflow definitions into the YAML Argo Workflows needs on Kubernetes. Qian Li introduces DBOS durable workflows, where a database stores workflow state and completed step results so execution can resume after crashes, API failures, long waits, or human input. Alan Nichol focuses on customer-facing agents. He argues that atomic function calls leave too much control flow to the language model, which makes business processes hard to test and debug. His process-calling model gives the agent stateful processes with explicit steps, branching, and reusable logic. Together, the talks favor ordinary software structures around the parts of an application that need predictable behavior.
Hera translates Python workflow code into Argo-compatible YAML
Elliot Gunton describes Hera as a Python SDK for Argo Workflows. Developers define templates as Python functions, assemble them into DAGs, and submit workflows through Python. Hera generates the YAML that Argo needs because Argo runs on Kubernetes and Kubernetes custom resources are expressed in YAML. This keeps business logic, orchestration logic, and submission code in one Python-based workflow. The approach also gives developers code completion, type hints, testing frameworks, and Python versioning instead of forcing them to maintain long YAML files.
Hera's script runner makes workflow functions testable in Python
Hera's inline script templates do not preserve Python input types or return values in a useful way. Its script runner addresses that by running the function through a Hera module inside a container. The runner validates inputs against the declared types, deserializes JSON, and allows the function to return values. Hera also integrates with Pydantic, so template inputs and outputs can use Pydantic models with type hints and structured validation. User-defined type annotations can handle binary outputs such as a pandas DataFrame written as a Parquet file.
AI workflows need checkpoints because retries can repeat harmful work
Qian Li lists failures that can occur during an AI workflow: downloads can fail, indexing can run out of memory, databases can become unavailable, models can return errors, APIs can impose rate limits, and users can take a long time to respond. A whole-workflow retry can repeat completed work, duplicate an email, corrupt data, waste model spend, and delay recovery. Durable workflows create save points by recording the workflow input and each completed step's output. After a crash, the system skips recorded steps and resumes from the unfinished step.
DBOS uses a database as the workflow engine and recovery record
DBOS runs inside the application process and stores workflow state in PostgreSQL. Developers decorate normal Python or TypeScript functions as workflows and steps. Workflows need deterministic control flow so they can replay safely, while calls to language models and other external systems belong in steps that can retry with exponential backoff. DBOS also provides durable queues, sleeps, timeouts, events, cron jobs, cancellation, resumption, and workflow forking. These features support long waits, human input, rate limits, and changes to workflow code without rerunning every earlier step.
Durable execution fits data pipelines, agent loops, and agent tools
Li gives three uses for durable workflows. A data pipeline can index documents or websites and resume after a crash without repeating completed work. An agent loop can decide its next action while durable steps handle model calls and tools. Individual tools, including MCP server tools, can themselves be durable subworkflows. In the flight-monitoring example, DBOS supports dynamically generated workflows, waits that last days, retries with exponential backoff, exactly-once email behavior through idempotency keys, parallel crawling through durable queues, and periodic execution through durable cron jobs.
Customer-facing agents need stateful processes rather than atomic tools
Alan Nichol says function calling works poorly when a customer describes a problem in everyday language and the business has a defined way to resolve it. A complaint about a missing order may require checking fulfillment, delivery status, customer history, and policy before deciding what to do. Atomic tools leave the language model to choose the next call through intermediate reasoning text. Nichol calls this 'prompt and pray' because steps can appear, disappear, or occur in a different order, and debugging becomes trial and error.
A process call keeps business control flow explicit across conversation turns
In Nichol's process-calling model, the language model invokes a stateful process rather than a single atomic operation. The process owns shared state, interacts with backend APIs, asks the user for missing information, and drives the conversation through several steps. The business can define branching logic and reusable subprocesses without writing every possible conversation path. A function call is a special case of process calling where the process has one step. Nichol says this gives deterministic business logic, simpler debugging, modular composition, lower token use, and lower latency.
The language model should handle genuine uncertainty while software handles known rules
Nichol's closing advice is to identify which parts of an agent really change from one interaction to another. Those parts can use an LLM. Known business rules and repeatable execution should remain traditional software. This division limits regressions caused by prompt changes and makes it possible to test and reuse the parts of the system that have fixed entry and exit conditions.
