DEV Community: Casper Nielsen

A Durable Google ADK Agent Needs Something to Notice the Crash

Casper Nielsen — Tue, 03 Nov 2026 18:10:22 +0000

Google ADK goes further on durability than most agent frameworks. Every interaction – user message, LLM response, tool call, tool result, state change – is recorded as an immutable Event. Turn on ResumabilityConfig(is_resumable=True), re-invoke with the original invocation_id, and completed tool results come back from the event history. Only the tool that failed runs again.

The gap is in who starts that replay.

Four minutes in, then a pod eviction
An ADK agent is four minutes into a three-tool task. Two tools have finished and their results are in the event history. The third has started. Then the pod gets evicted, and when it comes back, nothing happens.

Nothing inside ADK notices the crash. From outside, an agent that finished, an agent waiting on a slow tool and an agent whose process was killed look the same. The caller has to work out which one it's looking at and re-invoke with the right ID. If you run several replicas, there's a second problem: ADK has no coordination layer across them, so without external locking two runners can pick up the same task.

What a durable ADK agent needs
I'd list three things. A record of completed steps, which ADK already has. Something that notices a dead run and restarts it without a person or a cron job doing the detecting. And exactly one worker owning each run at a time.

The last two are runtime jobs. You can build them next to ADK – a watcher, a lock, a re-invoke path – or run the agent on something that already does them.

Moving recovery into the runtime

pip install "diagrid[adk]"
dapr init

from google.adk.agents import LlmAgent
from google.adk.tools import FunctionTool
from diagrid.agent.adk import DaprWorkflowAgentRunner

def book_venue(city: str) -> str:
    return f"Venue held in {city}"

def order_catering(headcount: int) -> str:
    return f"Catering ordered for {headcount}"

def send_invites(city: str) -> str:
    return f"Invites sent for {city}"

agent = LlmAgent(
    name="event_planner",
    model="gemini-2.5-flash",
    tools=[FunctionTool(book_venue), FunctionTool(order_catering), FunctionTool(send_invites)],
    instruction="Plan an event by calling the three tools in sequence.",
)

runner = DaprWorkflowAgentRunner(name="event-planner", agent=agent, max_iterations=10)
runner.start()
out = runner.run_sync(user_message="Plan a 40-person meetup in Copenhagen", session_id="cph-meetup")
print(out.final_response)
runner.shutdown()

Run it with dapr run --app-id event-planner -- python planner.py. The agent definition is plain ADK, so it moves over unchanged.

Each tool call now executes as a Dapr workflow activity, and the workflow log stores the activity's input, output and status, separately from ADK's event history. If the process dies, a durable reminder fires because the activity didn't complete, the workflow reactivates on a healthy replica, and it resumes from the last completed activity. Recovery goes through the workflow log instead of ADK's invocation_id replay path, so no caller has to detect anything or remember an ID.

A workflow instance also has a single ID and runs in one place at a time, which takes care of two replicas grabbing the same task.

Where I'd start
Pick the ADK agent with the longest runs, since it has the most finished work to lose, and check who re-invokes it today when a pod goes away. If nobody does, that agent is the first one to wrap. The Google ADK page goes through recovery in more detail: https://www.diagrid.io/learn/google-adk-durable-execution

How Do You Make a CrewAI Agent Survive a Crash?

Casper Nielsen — Thu, 29 Oct 2026 09:34:51 +0000

Run it under a durable workflow, so every tool call is saved as it completes. For CrewAI durable execution, that's one wrapper class around the agent you already have: DaprWorkflowAgentRunner turns each tool call into a Dapr workflow activity, and after a crash the run continues from the last completed one instead of starting over.

What happens without it
crew.kickoff() runs the whole task inside your Python process. The tool results the agent has gathered and its place in the reasoning loop live in that process's memory. If a deploy or an OOM kill takes the process out halfway, the task starts again from the top, and every tool it already called gets called again.

The change

pip install "diagrid[crewai]"
dapr init

from crewai import Agent, Task
from crewai.tools import tool
import dapr.ext.workflow as wf
from diagrid.agent.crewai import DaprWorkflowAgentRunner

@tool("Search the web for information")
def search_web(query: str) -> str:
    return f"Results for: {query}"  # swap in your real search tool

agent = Agent(
    role="Research Analyst",
    goal="Analyse market trends",
    backstory="A careful analyst who cites sources",
    tools=[search_web],
    llm="openai/gpt-4o-mini",
)

task = Task(
    description="Research Q4 trends in durable execution for AI agents",
    expected_output="Five bullet points with sources",
    agent=agent,
)

runner = DaprWorkflowAgentRunner(agent=agent, name="market-research", max_iterations=10)
runner.start()

run_id = "q4-trends"
client = wf.DaprWorkflowClient()
if client.get_workflow_state(run_id) is None:
    out = runner.run_sync(task=task, session_id=run_id, workflow_id=run_id, timeout=600)
    print(out.final_response)
else:
    state = client.wait_for_workflow_completion(run_id, timeout_in_seconds=600)
    print(state.serialized_output)

runner.shutdown()

dapr run --app-id market-research -- python crew_app.py

The Agent and Task are the same objects you'd hand to a Crew. The runner takes the place of kickoff().

What gets saved
Each tool call runs as a workflow activity. When it finishes, its input and output go into the workflow history in your state store. If the process dies, the Dapr runtime reactivates the workflow and replays it. Completed activities return their saved results, and execution continues from the first one that hadn't finished, with the agent's local state restored.

The fixed run_id is there so a restarted script finds the unfinished run and waits on it, rather than starting a second copy of the same task.

Where it stops
An activity that was mid-flight when the process died runs again from its start, because nothing recorded its result. For a search tool that costs you one extra search. For a tool that sends an email or writes a record, pass an idempotency key made from the run ID and the step, and let the receiving system drop the repeat.

Takeaway
If a CrewAI agent runs longer than the gap between your deploys, wrap it, give each run a stable ID, and make a list of which of its tools write to something. The CrewAI page has the rest: https://www.diagrid.io/learn/crewai-durable-execution

Give it a spin and lmk what breaks 👀

A Multi-Agent Workflow With MCP Tools in About 60 Lines

Casper Nielsen — Tue, 20 Oct 2026 20:27:30 +0000

A Multi-Agent Workflow With MCP Tools in About 60 Lines

An MCP agent demo is usually one agent calling one tool server. Add a second agent and a hand-off between them, and a boring question shows up fast: if the process dies between agent one and agent two, what runs again?

Below is the smallest version I'd show a team. A researcher agent gets its tools from an MCP server, a writer agent turns the findings into a summary, and a Dapr workflow runs them in order. Each agent call is a workflow activity, so its result is recorded before the next step starts.

What you need

pip install dapr-agents
dapr init

Plus an MCP server you already have running (this example connects over SSE) and an API key for whichever LLM provider you've configured.

The code

import asyncio
import dapr.ext.workflow as wf
from dapr_agents import Agent
from dapr_agents.tool.mcp import MCPClient

wfr = wf.WorkflowRuntime()

async def load_mcp_tools():
    client = MCPClient()
    await client.connect_sse(server_name="research", url="http://localhost:8000/sse")
    return client.get_all_tools()

researcher = Agent(
    name="researcher",
    role="Finds facts with the tools it has",
    instructions=["Use the MCP tools. Return bullet points with sources."],
    tools=asyncio.run(load_mcp_tools()),
)

writer = Agent(
    name="writer",
    role="Turns research notes into a short summary",
    instructions=["Write 150 words. Use only facts from the notes."],
)

@wfr.activity(name="research")
def research(ctx, topic: str) -> str:
    return str(asyncio.run(researcher.run(f"Research: {topic}")))

@wfr.activity(name="write")
def write(ctx, notes: str) -> str:
    return str(asyncio.run(writer.run(f"Summarise these notes:\n{notes}")))

@wfr.workflow(name="research_and_write")
def research_and_write(ctx: wf.DaprWorkflowContext, topic: str):
    notes = yield ctx.call_activity(research, input=topic)
    summary = yield ctx.call_activity(write, input=notes)
    return summary

if __name__ == "__main__":
    wfr.start()
    client = wf.DaprWorkflowClient()
    run_id = "research-demo"
    if client.get_workflow_state(run_id) is None:
        client.schedule_new_workflow(
            workflow=research_and_write,
            input="durable execution for AI agents",
            instance_id=run_id,
        )
    state = client.wait_for_workflow_completion(run_id, timeout_in_seconds=600)
    print(state.serialized_output)
    wfr.shutdown()

Run it with the sidecar:

dapr run --app-id mcp-agents -- python app.py

The fixed run_id matters. On a restart the script finds the existing workflow instead of starting a fresh one, and the runtime carries on with it.

Break it on purpose
Add time.sleep(30) at the top of write (and import time). Start the app, wait until the log shows the research activity completed, then Ctrl+C. Start it again with the same command.

The workflow picks up at write. The researcher's MCP calls don't run a second time, because their result is already in the workflow history. With a plain script you'd be back at the top, calling every MCP tool again and paying for every LLM turn again.

Where this version stops
The checkpoint here is per agent. If the process dies halfway through the researcher, the whole research activity runs again, MCP calls included. That's fine for read-only tools like search. If your MCP agents call tools that write – open an issue, post a message, update a record – swap Agent for DurableAgent, which runs the agent loop itself as a workflow, so each tool call gets its own recorded step.

The researcher and writer are placeholders. Point load_mcp_tools at your own MCP server, run the restart test, and lmk what breaks.

Durable Sessions for the Claude Agent SDK, in One Prompt

Casper Nielsen — Tue, 13 Oct 2026 06:52:34 +0000

We shipped a Claude Agent SDK executor in Dapr Agents with durable sessions and human approvals. Meaning: your Claude-built agent survives a crash mid-task, resumes with its session intact, and waits for an approval for as long as the approval takes – through restarts and deploys.

Getting started is rather easy:

pip install dapr-agents
dapr init

Then paste this into your agent definition:

from dapr_agents import DurableAgent
from dapr_agents.executors import ClaudeAgentExecutor

agent = DurableAgent(
    name="reviewer",
    executor=ClaudeAgentExecutor(session_store="statestore"),
    require_approval=["merge_pr", "deploy"],
)
agent.start()

Now break it on purpose, because that's the whole point:

Give it a multi-step task.
kill -9 the process somewhere in the middle.
Start it again. The session resumes where it stopped and the steps already completed come back from the journal, not from re-running Claude.
Trigger an approval-gated tool, close your laptop, approve tomorrow. The wait survives because it lives in the workflow, not in memory.

All behavior was checked against dapr-agents main; the release notes have the exact versions: https://github.com/dapr/dapr-agents/releases

Same machinery works for LangChain Deep Agents. The adapter landed earlier this year in our diagrid python package, and deep agents with long tasks are exactly where durable sessions pay off.

If you want the guided version, the Dapr Agents track at Dapr University is free: https://www.diagrid.io/university/dapr-agents

It's that easy to get started. Give it a spin and lmk what you think 👀

Hooks: Steer Your Agent Before the LLM Call

Casper Nielsen — Fri, 09 Oct 2026 07:51:25 +0000

Small feature, outsized leverage: Dapr Agents lets you register hooks around the agent loop where the before_llm_call being the one I use the most.

from dapr_agents import DurableAgent

def add_live_context(ctx):
    ctx.messages.append(web_search(ctx.task))  # fresh context, every call

agent = DurableAgent(
    name="researcher",
    hooks={"before_llm_call": add_live_context},
)

Everything the hook does, lives inside the durable workflow, so a crash after the hook but before the call replays cleanly with no lost context. That's the difference between bolting logic onto the loop and having the runtime own it. It's important to note here that the hook itself has to be replay safe. Furthermore, the hook author needs to define whether this hook is deterministic or not. This has impact on replaying. A web search, as the above example is, will not be deterministic and thus will rerun. For live context, this is great and probably what we want. For validating user tokens, this is equally great - otherwise we'd just roll an approval on a potentially expired token!

Uses we've seen in the wild: injecting fresh web context (my webinar demo), token-budget enforcement before the spend happens, redacting PII on the way in - and on the way out too. The latter is powerful to use if your agent handles sensitive data you'd want to mask before sending to an LLM provider.

The webinar takes you through a full example with Tavily and Chainlit to enrich a models answer with fresh web results: https://www.diagrid.io/webinars/make-your-llm-agent-production-smart

Give it a spin and lmk what you think!

[Boost]

Casper Nielsen — Tue, 06 Oct 2026 20:01:11 +0000

Marc Duiker for Diagrid

Oct 5

What's New in the Dapr Dev Dashboard for Local Workflow Debugging

#dapr #debugging #programming

7 min read