Multi-step agents में compound failure rates बेरहम हैं — ये तो हम establish कर चुके हैं। सात steps का workflow अगर हर step पर 95% reliable है, तो end-to-end सिर्फ ~70% बचता है। दस में से तीन बार सब उड़ जाता है। लेकिन असली problem जो कोई fix नहीं कर रहा: जब step four HTTP 500 फेंकता है, तो पहले के तीन steps का क्या? Slack message जो पहले ही भेज दिया, database row जो पहले ही लिख दी, Jira ticket जो पहले ही file हो गया। तुम्हारे agent को पता ही नहीं कौन से steps complete हुए। कोई checkpoint नहीं — कोई saved position नहीं जहाँ से resume करे। और कोई compensation logic नहीं — आधे-अधूरे काम का automatic "undo" नहीं।

Failure rate देखना step one है। Failure से बचना step two है। Step two कोई ship नहीं करता।

Recovery का नाटक

तीनों major agent runtimes ने April में recovery features launch किए। किसी ने भी recovery actually solve नहीं किया।

Anthropic के Managed Agents (8 April) append-only event log use करते हैं — एक write-once diary जिसमें agent ने जो भी किया सब लिखा है। Crash हुआ? Reboot करो, diary पढ़ो, आगे बढ़ो। उनकी engineering team: "Harness में कुछ भी crash survive करने की ज़रूरत नहीं।" सुनने में resilient लगता है। लेकिन failed tasks के लिए कोई dead-letter queue नहीं, कोई exactly-once guarantee नहीं कि हर action सिर्फ एक बार चले, और completed side effects को rollback करने का कोई तरीका नहीं।

OpenAI का Agents SDK update (15 April) snapshotting और rehydration लाया — container restarts के बीच agent state को save और restore करना। लेकिन ये message history persist करता है, execution state नहीं। Model को याद है उसने क्या बोला; ये track नहीं करता कि उसने क्या किया।

Google ADK (Cloud Next पर announce हुआ, 22 April) SequentialAgent, ParallelAgent, LoopAgent plus एक ResumabilityConfig ship करता है। Fine print: caller को interruption detect करके manually re-invoke करना होगा। Automatic recovery नहीं।

तीन अलग-अलग durability approaches। तीनों execution को inference loops की तरह model करते हैं — "think → call tool → observe → repeat." कोई भी इसे durable state machine की तरह model नहीं करता — एक ऐसा system जो exactly track करे कि वो किस state में है और कौन से transitions valid हैं, जैसे एक vending machine जिसे power outage के बाद भी याद रहता है कि तुमने पैसे डाल दिए थे।

Solutions जो पहले से मौजूद हैं (AI के बाहर)

Workflow engines ने durable execution एक दशक पहले solve कर लिया था। AI industry ने बस अभी तक adopt नहीं किया।

Temporal हर step को एक retryable, replayable activity में wrap करता है। Workflow बीच में crash? Temporal last completed activity से replay करता है — शुरू से नहीं। Temporal-wrapped agent step ऐसा दिखता है:

@activity.defn
async def file_jira_ticket(ctx: AgentContext) -> TicketResult:
    """Temporal retries this automatically on failure.
    If the agent crashes mid-workflow, it replays
    from the last completed activity — not from scratch."""
    return await ctx.tools.jira.create_issue(
        summary=ctx.draft.title,
        idempotency_key=ctx.run_id  # prevents duplicate tickets
    )

वो idempotency_key — एक unique ID जो ensure करती है कि same request दो बार execute न हो — बस यही एक चीज़ है जो "production-grade" और "impressive demo" के बीच का फ़र्क है।

Cloudflare का Project Think (15 April) ने बिल्कुल अलग रास्ता चुना: per-agent SQLite databases, step.do() checkpoints, और zero-cost hibernation। हर agent एक durable isolated entity है जिसका अपना persistent state है, किसी centralized orchestrator में कोई job नहीं। जो teams पहले से Cloudflare Workers पर हैं, उनके लिए ये arguably सबसे clean path है — कोई external workflow engine नहीं, कोई message broker नहीं, बस durable objects जिनमें built-in checkpointing है।

Restate इन दोनों के बीच बैठता है: Temporal से lighter, raw durable objects से ज़्यादा structured। ये exactly-once guarantees देता है journal-based replay mechanism के साथ, और Google ADK के साथ direct integration patterns publish कर चुका है।

बेचैन करने वाला middle ground

यहाँ वो problem है जो कोई acknowledge नहीं करना चाहता: gap दोनों तरफ़ से है।

Workflow engines LLM की भाषा नहीं बोलते। उन्हें token budgets समझ नहीं आतीं — कि एक AI call में कितना text process हो सकता है। वो model fallback routing handle नहीं कर सकते — जब expensive model rate limit हिट करे तो cheaper model पर switch करना। उन्हें prompt versioning, context window management, या tool-call schema evolution का कोई concept नहीं। Agents को Temporal पर bolt करने का मतलब है "workflow step" और "inference call" के बीच एक translation layer लिखना — और हर बार maintain करना जब तुम्हारा model provider अपना API बदले।

Agent platforms durability नहीं समझते। वो tool calls को inference के ephemeral side effects मानते हैं, state transitions नहीं जिन्हें transactional guarantees चाहिए। एक LLM का tool call करना philosophically अलग है एक workflow step के function call से: LLM decide कर सकता है tool दोबारा call करे, अलग tool call करे, या ऐसा tool hallucinate करे जो exist ही नहीं करता। Workflow engines deterministic step definitions assume करते हैं। LLMs definitionally non-deterministic हैं।

कोई भी side गलत नहीं है। दोनों एक ही problem के अलग-अलग हिस्से solve कर रहे हैं।

तुम्हारे लिए इसका क्या मतलब है

अगर तुम्हारा agent तीन से ज़्यादा steps में external state modify करता है — emails भेजता है, databases लिखता है, third-party APIs call करता है — तो तुम्हें अभी workflow-engine guarantees चाहिए। तुम्हारा agent platform ये provide नहीं करता। तुम्हारे पास तीन options हैं:

  1. Temporal/Restate खुद bolt करो। Real integration complexity, लेकिन battle-tested durability। Worth it अगर तुम agents production में actual SLAs के साथ चला रहे हो।
  2. Cloudflare-native जाओ। अगर तुम पहले से Workers पर हो, Project Think बिना orchestration overhead के durable agents देता है। Trade-off: platform lock-in।
  3. Failure rate accept करो और manual reconciliation tooling बनाओ। Honestly, internal tools जहाँ users माफ़ कर दें, वहाँ ये rational हो सकता है। बस इसे "production-ready" मत बोलो।

Convergence inevitable है। पहला vendor जो durable state-machine execution को default agent primitive की तरह ship करेगा — afterthought नहीं, third-party integration नहीं — वो तीनों runtimes के ऊपर production reliability layer का मालिक बन जाएगा। Temporal को पता है; उनका OpenAI Agents SDK integration एक land grab है। Cloudflare को पता है; Project Think agents को platform feature बनाने के लिए design किया गया है।

तुम्हारा सात-step demo अभी भी खूबसूरती से चलता है। Production में ship करने का मतलब अभी भी ये है कि तुम decide करो कि कौन सा failure mode तुम्हें चलेगा।