"The hardest part of an AI agent isn't generating the next response. It's remembering what it was doing three days later." – Arash Khazaei, Co-founder & CTO, Strada
The customer#
Strada is the AI operating layer for insurance operations. Its agents work across the front office (voice, chat, SMS, email) and the back office (document processing, endorsements, claims), and write results back into the systems of record where the work lives.
Strada works with enterprise P&C carriers, MGAs, and TPAs, including Hippo, Clearcover, Hagerty.
Strada started with voice, where a workflow begins and ends in minutes: the call starts, the agent works, the call ends, and the state lives in memory. Email broke that pattern immediately.
The challenge#
A policyholder files a claim by email. The agent identifies what's missing and requests a declarations page. Three days later a PDF arrives; the agent extracts the fields, checks them against the policy system, flags a discrepancy, and routes to a human adjuster who may take another day before the agent closes the loop. That is one workflow: inbound emails days apart, document extraction, policy-system API calls, a human decision midway, and an automated reply, all as one continuous process. Once an agent has to survive deployments, wait for humans, and coordinate with external systems, it stops being request-response software and becomes workflow orchestration.
Some of that is standard distributed-systems work: retries, state that survives Worker restarts, multi-day timers, deployment safety mid-execution. The harder problems were specific to AI agents running asynchronously:
- Partial failure. An email with four attachments should not lose three good extractions because the fourth failed.
- Concurrency over shared context. Two threads from the same customer, minutes apart, load the same context and can produce inconsistent responses.
- Side-effect safety on replay. After a crash and restart, the agent must repeat the decision to send without re-sending the email.
Examples of issues from asynchronous AI agents
Why Temporal?#
Strada didn't adopt Temporal for any single feature. Retries, durable state, multi-day timers, deployment safety, partial failure, concurrency, and side-effect safety are each a distributed-systems problem on their own. Together they describe one thing: an agent that runs across days, humans, external systems, and deployments is not request-response software. It is a durable workflow.
That property is durable execution. Instead of building retries, state persistence, timers, and replay safety as bespoke infrastructure, Strada got them as primitives. The design rule that followed: Workflows own orchestration and stay deterministic, so they can replay from an event log after a restart; Activities own side effects like extraction, API calls, and sending mail. Completed Activity results are recorded in Event History, so Workflow replay can use those results without re-executing the completed Activities.
The solution#
Each email Workflow runs in four phases, intake, extraction, reasoning, and delivery, with the parent orchestrating between them without ever touching the network or database directly. What matters is where the boundaries sit.
Attachment processing is a Child Workflow, so if three of four attachments extract cleanly and one fails, the parent continues with what it has instead of retrying everything. The AI reasoning loop is also a Child Workflow, bounded to ten tool-calling iterations, so a timeout there never takes down the parent. The response is persisted before it is sent, because in insurance, losing the record of what the agent decided is worse than a failed delivery; a failed send still leaves the message and its full reasoning trace intact. Activities are grouped by failure profile rather than one shared Retry Policy: document extraction can retry for up to six hours when a provider is unavailable, parsing timeouts in minutes, and configuration errors fail fast instead of burning retries.
Solving concurrency with a serial orchestrator#
The hardest problem was one the team didn't initially see: when multiple emails sharing the same customer context arrive close together, each workflow loads that context and reasons independently, and they can produce inconsistent responses. The fix was a serial orchestrator, a long-lived Temporal Workflow that serializes reasoning where context overlaps. An email Workflow signals it and suspends, possibly for hours; the orchestrator processes one request at a time and signals the result back.
The conventional version of this is a message broker with a consumer group and a reconciliation service. The serial orchestrator does it as one Workflow: the queue lives in Workflow state, ordering is a loop with a condition wait, and pending requests survive deploys and restarts through the Event History, with no external store.
The results#
Temporal gave Strada a durable execution layer for workflows that span days, survive infrastructure changes, and recover from transient failures without losing state.
| Result | Detail |
|---|---|
| Durable long-running workflows | Workflows wait days for a customer or human response and resume from exactly where they stopped. |
| Automatic recovery | Transient failures like provider rate limits are handled by configured Retry Policies, with no special-case logic. |
| Independent failure handling | Attachments and other steps fail and retry independently rather than restarting the whole Workflow. |
| Safe side effects | Decisions and reasoning traces are persisted before delivery, so a failed send never loses the record. |
| Reliable concurrency | A serial orchestrator keeps agents over overlapping context from making conflicting decisions. |
| Less infrastructure code | State, ordering, waiting, retries, and recovery live in Temporal, not custom queues and reconciliation services. |
The clearest proof is the ordinary case: a Workflow suspended while waiting for a human. Between the agent's request and the customer's reply, Strada has shipped new code, restarted Workers, and rescheduled pods. The Workflow resumes exactly where it left off from the Event History, with no state database or checkpoint to reload. A rate-limit spike behaved the same way: the extraction provider began returning 429s, and because those Activities carry a six-hour window with backoff, Temporal retried until it recovered, with no special handling.
The patterns generalized beyond email. Strada now uses the same architecture, activity-per-side-effect, signal-based coordination, and self-resetting long-lived orchestrators, for Workflows where the AI, not a static graph, decides the next step.
The takeaways#
What Strada got wrong. Email surfaced durable-workflow problems voice never did, and a few came the hard way.
- ContinueAsNew came late. The first serial orchestrator never reset its Event History, and replay slowed once it had processed a few hundred requests. Long-lived Workflows with unbounded Event Histories should plan for Continue-As-New from the start.
- Early Activities were too coarse. One Activity parsed, extracted, and analyzed in a single function, so any failure retried all of it. Splitting them let Temporal retry only the step that failed.
- Concurrency was a surprise. The team didn't anticipate that agents reasoning independently over shared context could conflict, and had to hit the failure mode to see it.
These were learning-curve mistakes, not platform limits. The real takeaway is to model orchestration as deterministic code, isolate every side effect, and let the platform handle failure, restarts, and time.
