What Happens When Your Spring AI Agent Restarts Mid-Conversation?
Spring AI brings agents into the Spring ecosystem you already run: ChatClient, tool calling, advisors, and Spring Boot auto-configuration. But an agent run is a blocking in-process call. A deployment rollout, an OOM kill, or a pod eviction in the middle of a multi-step tool-calling loop loses everything the run had already completed and paid for. Diagrid makes every ChatClient call a durable Dapr workflow, so agent runs resume from their last completed step instead of starting over.
Crash-safe execution
One dependency, no agent rewrite
Built on open-source Dapr
Production Gap Analysis
Why Spring AI Alone Isn't Production-Ready
Spring AI is a well-designed abstraction over models, tools, and prompts. What it doesn't provide is the execution infrastructure underneath: nothing checkpoints a run in progress, nothing notices when one dies, and nothing resumes it.
No durable execution
A ChatClient call is a blocking in-process call. The multi-turn tool-calling loop lives in JVM heap and nowhere else. Restart the process mid-run and the conversation, the tool results, and the money already spent on LLM tokens are gone.
Chat memory is not a checkpoint
Spring AI's ChatMemory persists the conversation transcript, not execution progress. After a restart the transcript is intact but nothing records which tool calls already completed, so the model is free to call them again.
No failure detection
There is no supervisor watching an agent run. When the pod handling it disappears, the run does not fail loudly — it simply stops existing, and nothing retries it.
Long tool calls are tied to the request
A tool that waits on a slow external system holds a request thread for its whole duration. If the caller times out or the connection drops, the work in flight is unrecoverable because its only handle was that request.
No execution history to debug
Diagnosing a bad agent run means reconstructing it from application logs. There is no per-step timeline showing which tools ran, in what order, with what inputs and outputs.
No workload identity
Spring Security protects your HTTP endpoints. It does not give the agent a cryptographic identity or mTLS between the services and tools it calls.
Integration
From In-Process to Durable
The Spring Boot starter attaches a Spring AI advisor to the auto-configured ChatClient.Builder, so building your client from that managed builder is the whole integration. Each call then runs as a Dapr workflow whose completed LLM turns and tool calls are never re-executed.
@Componentclass ResearchAgent { private final ChatClient client; ResearchAgent(ChatModel model) { this.client = ChatClient.builder(model) .defaultSystem("You are a research analyst") .defaultTools(new MarketTools()) .build(); } String analyze(String question) { // Blocking and in-process. A restart here // loses every tool call already paid for. return client.prompt(question) .call() .content(); }}// The only dependency you add:// io.diagrid:diagrid-spring-ai-starter@Configurationclass Agents { // Build from the Spring-managed builder — the // durable advisor is already attached to it. @Bean ChatClient researchAgent(ChatClient.Builder builder) { return builder .defaultSystem("You are a research analyst") .defaultTools(new MarketTools()) .build(); }}// analyze() is unchanged. Every call now runs as the// workflow spring-ai.researchAgent.workflow: crash// mid-conversation and it resumes from the last// completed step.Comparison
From Prototype to Production
What changes when you add Diagrid to your Spring AI agents.
Enterprise-Grade
Enterprise Infrastructure for Spring AI
Everything your team needs to run Spring AI agents in production. Built on Dapr, the CNCF project trusted by thousands of enterprises.
Zero-Trust Security
Every agent gets a SPIFFE-based cryptographic identity through Dapr's built-in security model. All communication is encrypted with automatic mTLS. Fine-grained policies control which agents can access which tools.
End-to-End Observability
Distributed tracing for every workflow execution with per-step input and output inspection. Built on OpenTelemetry, so traces integrate with the tools your team already uses.
Multi-Region Failover
Deploy across regions with active-passive failover. If a region goes down, Dapr Workflows automatically resume in the standby region from their last checkpoint.
Durable State Store
Dapr Workflows persist state to a remote store after every activity. Survives process crashes, OOM kills, deployments, and infrastructure failures. Use any supported database as the backend.
Multi-Instance Coordination
Dapr's actor placement service ensures each workflow is processed by exactly one instance. Scale horizontally without duplicate executions or race conditions.
Full Execution History
Complete audit trail for every workflow with deterministic replay. Re-run any past execution for debugging, compliance, or analysis. All built on the open-source Dapr project.
How It Works
Three Steps to Production
Keep your existing Spring AI code. Add production reliability in minutes.
Build with Spring AI
Define your agent, tools, and logic using Spring AI exactly as you normally would. No special patterns or abstractions required.
Wrap with Diagrid
Add one import and wrap your agent with DaprWorkflowAgentRunner (or DaprWorkflowGraphRunner for LangGraph). Each tool call becomes a durable Dapr workflow activity.
Deploy to production
Run with Dapr Workflows handling crash recovery, state persistence, distributed coordination, security, and observability. Your agent code runs locally or in the cloud.
FAQ
Frequently Asked Questions
Deploy Spring AI to Production Today
Add durable execution to the ChatClient you already have. One dependency, built on open-source Dapr. Start free, no credit card required.
