AI Agent Proof of Work vs Proof of Continuity
You're running an agent in production. It answers a customer, writes to your database, triggers a payment. Then the process dies. The work is gone. The payment didn't happen. The customer is staring at a spinner.
Nobody asks if the agent can reason. They ask if it finished the job.
That's the difference between proof of work and proof of continuity. Proof of work says "the agent produced a correct output." Proof of continuity says "the agent survived long enough to make that output matter." Most teams I meet are obsessed with the first. They're wrong. The second is what kills you in production.
This article is about ai agent proof of work vs proof of continuity — why the distinction matters, how to design for both, and where the industry keeps getting it backwards.
The Work Fallacy
Let me start with a story.
In March 2026, a client at SIVARO was running a support automation agent. It was beautifully engineered — solid prompts, good tooling, evals showing 94% task success in staging. In production, it completed 38% of tickets end-to-end. The other 62% failed halfway. The agent would retrieve a customer record, then crash. It would draft a refund, then lose the context. The work was correct. The continuity was zero.
Here's what most people don't understand: an AI agent is not a function call. It's a process. A stateful, long-running, failure-prone process. And processes need different guarantees than functions.
Proof of work is the traditional evaluation paradigm. You give the agent a task. It produces an output. You grade the output. This works fine for benchmarks. It works fine for chatbots. It works catastrophically for autonomous systems that touch real infrastructure.
Why? Because in production, the output isn't the product. The outcome is. And outcomes require the agent to survive interruptions, retries, partial failures, and state loss. That's proof of continuity.
Let's define both clearly:
- Proof of Work: The agent's output satisfies the task specification. Measured by accuracy, completeness, correctness. This is what evals measure.
- Proof of Continuity: The agent's execution path remains valid and recoverable across time, failures, and state changes. Measured by liveness, durability, idempotency. This is what operations measure.
They're not either/or. But they require different design disciplines. And right now, the industry is heavily weighted toward the former.
Why Agent Systems Are Distributed Systems
At first I thought this was a terminology problem. Turns out it's a design problem.
Agent systems are distributed systems. Not "like" distributed systems. Not "inspired by" distributed systems. They are distributed systems, full stop. The Akka team made this argument and they're right. An agent is a node. A tool call is a remote procedure call. A context window is a state store. A model inference is a computation that can fail, time out, or return garbage.
Once you accept that framing, everything changes. You stop asking "how smart is the agent?" and start asking "what happens when the node dies mid-execution?"
This is the core insight behind ai agents distributed systems architecture explained: the failure modes you design for are the same ones you'd design for in any distributed system. Network partitions. Timeouts. Partial writes. Duplicate messages. Process crashes. The brain is different. The skeleton is the same.
Consider what Azure's agent design patterns actually describe. Orchestrator-worker. Router. Delegation. These are not new concepts. They're distributed systems patterns with LLM components swapped in. The orchestrator is a coordinator. The worker is a worker. The router is a load balancer with better conversational skills.
Once you see that, the problem of agent reliability stops being a prompt-engineering problem and becomes a systems problem. And systems problems need systems solutions: retries, queues, checkpoints, idempotency keys, circuit breakers.
The industry is catching up slowly. But most agent frameworks still treat the model call as the atomic unit. It isn't. The atomic unit is the entire workflow — from first input to final side effect. And that workflow needs to be durable.
Proof of Continuity Is a Design Pattern
Let's get practical. What does proof of continuity actually look like in code?
It looks like state you can recover. It looks like operations you can retry. It looks like a system that doesn't forget what it was doing just because a process died.
Here's a minimal example. Most agents I see in production look like this:
python
def run_agent(task):
result = llm_call(task)
return result
This is a function. It's not an agent. It has no memory, no recovery, no continuity. If the process dies mid-call, the task is lost.
A continuity-aware agent looks different. It separates state from execution:
python
import json
import redis
class DurableAgent:
def __init__(self, task_id, state_store):
self.task_id = task_id
self.state_store = state_store
self.state = self._recover()
def _recover(self):
state = self.state_store.get(self.task_id)
return json.loads(state) if state else {"step": "start", "context": {}}
def run(self):
while True:
step = self.state["step"]
if step == "start":
self._execute_step("start", self._do_start)
elif step == "tool_call":
self._execute_step("tool_call", self._do_tool_call)
elif step == "finalize":
return self._do_finalize()
else:
raise ValueError(f"Unknown step: {step}")
def _execute_step(self, step_name, fn):
try:
result = fn(self.state["context"])
self.state["step"] = self._next_step(step_name)
self.state["context"].update(result)
self.state_store.set(self.task_id, json.dumps(self.state))
except Exception as e:
self.state["error"] = str(e)
self.state_store.set(self.task_id, json.dumps(self.state))
raise
That's not fancy. It's a state machine with a checkpointer. But it's the difference between an agent that loses a customer's refund request and one that picks it up exactly where it left off.
This is what I mean by ai agent proof of work vs proof of continuity: one evaluates the output, the other evaluates the journey. And the journey is where production systems actually fail.
The Four Patterns, Reframed
Let me tie this to the architecture patterns people actually use. The LangChain guide on multi-agent architectures and Google Cloud's design pattern guide both describe similar families: single agent, hierarchical, sequential, and mesh.
Here's my take after building these systems at SIVARO:
Single Agent
This is a service, not a system. Fine for simple tasks. Terrible for anything with multiple failure domains. You get continuity for free because there's nothing to coordinate. But you also get a single point of failure. If the agent crashes, everything crashes.
Hierarchical (Orchestrator-Worker)
This is the workhorse. The orchestrator manages state and delegates tasks. Workers are stateless. This is where proof of continuity matters most — the orchestrator needs to be durable, or the whole system loses its mind. The Azure Architecture Center covers this pattern well. My experience: it works best when workers are idempotent and the orchestrator is a state machine.
Sequential (Pipeline)
This is a workflow. Each stage's output feeds the next. The continuity requirement is brutal: if stage three fails, do you replay stage two? Do you reprocess the entire pipeline? You need checkpointing at every stage, or you're redoing work forever. Most teams don't do this. They just retry the whole pipeline. That's wasteful but often acceptable at small scale.
Mesh (Peer-to-Peer)
This is chaos. Agents talk to each other with no central coordinator. It's flexible, but continuity is nearly impossible to guarantee. There's no single point of state. You end up building a distributed consensus protocol for agents. Unless you have a really good reason, avoid this. The Confluent piece on event-driven multi-agent systems shows how to make this work with message brokers, but it requires discipline most teams don't have.
My recommendation: start with hierarchical. It's the best balance of control and resilience. And make the orchestrator durable.
The Continuity Stack
Proof of continuity isn't a single feature. It's a stack of guarantees. Here's what I insist on at SIVARO:
Liveness
Is the agent still running? Every agent needs a heartbeat. Not for monitoring theater — for actual recovery. If an orchestrator hasn't checked in for 30 seconds, a supervisor should be able to kill it and spin up a replacement.
Durability
Is the state safe? If the process dies, can you reconstruct what it was doing? This means persisting the agent's state at every step transition. Redis, Postgres, whatever. The storage doesn't matter. The discipline does.
Idempotency
Can you run the same step twice without causing a mess? This is the big one. Most agent tool calls are not idempotent. Sending an email twice is a disaster. Charging a card twice is a lawsuit. You need idempotency keys on every external call:
python
import uuid
def make_tool_call(tool_name, params, idempotency_key=None):
key = idempotency_key or str(uuid.uuid4())
response = tool_router.call(tool_name, params, idempotency_key=key)
return response
If the tool supports idempotency, great. If it doesn't, you need a wrapper that deduplicates. This is not optional. The event-driven patterns from Confluent emphasize this — you need event sourcing or at minimum a message log to make retries safe.
Recoverability
Can the agent resume from failure? This requires that your state includes enough information to reconstruct the next step. Store the context, the current step, and any partial results. Don't rely on the model to remember what it was doing — it won't.
What I've Seen Work in Production
Here's a concrete example from a production deployment at SIVARO in late 2025. A logistics client needed an agent to handle shipment exceptions — delays, damages, reroutes. The agent had to query a tracking API, update a CRM, and notify customers.
Our first version was a straightforward orchestration flow. It failed constantly. The tracking API would time out. The CRM would reject a write. The notification would fire before the update completed. Classic distributed systems failure modes.
We rebuilt it with a durable state machine. Every step persisted its result. Every external call had an idempotency key. Every retry resumed from the last completed step. The completion rate went from 62% to 97.5%. That's not a model improvement. That's a continuity improvement.
The lesson: your agent's intelligence is capped by the reliability of its environment. A brilliant agent with flaky infrastructure is worse than a mediocre agent with solid infrastructure. This is the fundamental argument for why ai agent proof of work vs proof of continuity is the wrong framing — it's not a contest. It's a dependency.
The Evaluation Gap
Here's the uncomfortable truth: we don't have good evals for continuity.
The arXiv survey on AI agent systems points out that most evaluation frameworks focus on task completion and output quality. They don't measure recovery time, failure tolerance, or state integrity. There's no standard metric for "how many retries did it take to finish the task?"
We need those metrics. At SIVARO, we've started tracking what we call the Continuity Score:
continuity_score = completed_tasks / (completed_tasks + failed_tasks + orphaned_tasks)
Orphaned tasks are the ones that started but never finished — the system lost track of them entirely. Those are the worst. A failure you know about can be retried. An orphan is gone forever.
We also track:
- Mean time to recover (MTTR) after an agent crash
- Percentage of tasks completed without any retry
- State recovery accuracy (does the restored state match the pre-crash state?)
These numbers tell you more about your production system than any benchmark. You can have perfect accuracy on a test set and still have a broken agent. The test set doesn't crash. Production does.
Proof of Work Still Matters
Don't misread this. I'm not saying proof of work is irrelevant. It's necessary. It's just insufficient.
You need both. Proof of work tells you the agent can reason. Proof of continuity tells you the agent can operate. One without the other is a toy.
Here's how I think about the division of labor:
- Development phase: focus on proof of work. Build the reasoning, test the tool calls, evaluate the outputs. This is where you iterate on prompts and models.
- Production phase: focus on proof of continuity. Build the durability, the retries, the idempotency. This is where you iterate on infrastructure.
The problem is that most teams don't switch phases. They treat production as "development with better monitoring." They don't rebuild the agent as a distributed system. They just deploy the development version and hope.
That's why so many agent pilots die in production. Not because the model isn't smart enough. Because the system isn't reliable enough.
The Cost of Ignoring Continuity
Let me put a number on this. In June 2026, a fintech startup came to us after their agentic onboarding flow failed during a pilot. The agent was supposed to verify identity, create an account, and set up a payment method. It worked 91% of the time in their test environment.
In production, it worked 44% of the time. The rest were partial completions — identity verified but account not created, account created but payment method missing. They had orphaned records all over their database.
The cost wasn't just the lost conversions. It was the support load. Every partial completion required a human to manually resolve. That's the hidden cost of broken continuity: you're not just failing tasks, you're creating manual remediation work.
A durable agent design would have prevented 80% of those issues. Not because the agent was smarter, but because the system was more recoverable. When a step failed, the agent would have retried or rolled back. Instead, it just stopped and left a mess.
A Pragmatic Framework
So how do you actually design for both? Here's the framework I use with clients. It's not academic. It's a checklist.
Step 1: Model the workflow as a state machine.
Every agent task is a sequence of steps. Define them explicitly. Don't let the agent improvise the entire workflow. The improvisation should happen within steps, not across them.
Step 2: Persist state at every step.
After each step, write the state to durable storage. Include the step name, the context, and any partial results. This is your recovery point.
Step 3: Make every external call idempotent.
This is non-negotiable. If you can't make the call idempotent, wrap it in a deduplication layer. Store the idempotency key in your state.
Step 4: Implement retries with exponential backoff.
Don't retry immediately. Wait. Then wait longer. Then give up and escalate. The Google Cloud architecture guide recommends circuit breakers for repeated failures. Do that.
Step 5: Test for continuity.
Don't just test task completion. Kill the process mid-task and see what happens. Restart it and verify it recovers. Duplicate a message and verify it doesn't double-execute. This is chaos engineering for agents. It's the only way to know if your continuity design actually works.
Here's a test harness pattern:
python
def test_continuity(agent, task, crash_point):
state_store = FakeStateStore()
agent = agent_with_crash(agent, task, crash_point, state_store)
try:
agent.run()
except SimulatedCrash:
pass
recovered_agent = DurableAgent(task.id, state_store)
result = recovered_agent.run()
assert result.status == "completed"
assert not result.duplicate_side_effects
If your agent can survive a crash at every step, you have continuity. If not, you have a demo.
When Proof of Work Is the Wrong Metric
There's a subtle trap here. Sometimes proof of work itself is the problem. Specifically, when you optimize for task completion accuracy, you often optimize for the wrong behavior.
Let me explain. If you measure an agent by whether it finishes a task, the agent will learn to finish tasks. Even when it shouldn't. Even when it's hallucinating. Even when it's making up tool results.
This is a known issue. The Akka blog post talks about how agent failures often come from "the brain" — the model — not the infrastructure. But I'd argue the brain and the infrastructure are entangled. A model that knows it can retry will be more honest. A model that knows it will be graded on completion will be more creative about "completing."
In production, I'd rather have an agent that says "I couldn't complete this task" and fails cleanly than one that fabricates a completion and causes downstream damage.
That means your evals need to measure failure quality, not just success rate. How does the agent handle a failed tool call? Does it retry? Does it escalate? Does it hallucinate a result? That's a proof of continuity question, but it shows up in your proof of work metrics.
The Solo Agent Continuity Problem
One more pattern worth addressing: the solo agent with a long-running task.
Imagine a research agent that's supposed to crawl 50 pages, synthesize findings, and write a report. This takes 15 minutes. In that time, the process might restart, the API might rate-limit, the context window might fill up.
This is the hardest continuity problem, because there's no orchestrator to manage state. The agent is on its own. The only solution is to make the agent's execution environment durable. That means checkpointing the agent's internal state — including the conversation history and any partial outputs — to external storage.
Most agent frameworks don't support this well. You have to build it yourself. At SIVARO, we've built a serialization layer that captures the full agent state and persists it after every model call. It's heavy, but it works. The agent can be killed and resumed at any point without losing context.
This is where I expect the industry to go. The frameworks that build native continuity support — durable execution, checkpointing, recovery — will win. The ones that treat agents as stateless functions will die.
What the Frameworks Get Wrong
Let me be blunt about the current tooling. Most agent frameworks are built for proof of work. They make it easy to define tools, call models, and evaluate outputs. They make it hard to do the distributed systems work: durable state, idempotent execution, failure recovery.
This is why so many agent deployments hit a wall. The framework gets you to a demo in a week. Then you spend a month rebuilding the state management, the retry logic, and the recovery paths.
I don't blame the frameworks. They're solving a different problem. They're optimizing for developer velocity, not production reliability. But if you're building real systems, you need both.
My advice: don't rely on the framework for continuity. Build it yourself. Use the framework for what it's good at — model orchestration, tool definition, prompt management. Build your own state machine, your own idempotency layer, your own recovery logic.
It's more work. But it's the difference between an agent that works in a demo and an agent that works in production. The LangChain architecture guide is honest about this: the framework handles orchestration, but you handle the rest.
The Future: Continuity as a First-Class Citizen
Here's my prediction for the next 18 months. Proof of continuity becomes the primary metric for production agent systems. Not because proof of work stops mattering, but because it becomes table stakes. Every model is getting smarter. The differentiator will be which system can actually execute reliably.
The arXiv survey already shows the trend: evaluation is shifting from task completion to long-term operation. There's more emphasis on "agent lifespan," "task durability," and "recovery efficiency." The vocabulary is changing.
I'm also seeing the infrastructure catch up. Durable execution platforms are adding agent support. Event brokers are adding agent-specific patterns. The Confluent event-driven patterns are a sign of this — they're applying proven distributed systems patterns to agent communication.
But the fundamental shift is conceptual. We're moving from "agents as smart functions" to "agents as durable processes." That's the ai agent proof of work vs proof of continuity evolution. And it's necessary.
Because in the end, nobody cares how smart your agent is. They care whether it gets the job done. And getting the job done — reliably, recoverably, at scale — is a distributed systems problem.
FAQ
Q: What's the simplest way to start implementing proof of continuity?
Start with a state machine and a checkpoint. Define your workflow steps, persist state after each step, and add recovery logic. That's 80% of the value.
Q: Do I need both proof of work and proof of continuity?
Yes. They're complementary. Proof of work ensures the agent is correct. Proof of continuity ensures it's reliable. You need both for production.
Q: How do I test for continuity?
Kill the agent mid-task. Restart it. Verify it recovers. Duplicate a message. Verify no double execution. Fail a tool call. Verify the retry logic. That's the testing process.
Q: Can I get continuity from a managed framework?
Some frameworks offer durable execution, but they're still limited. You'll likely need to build your own state management and idempotency layers. The frameworks are getting better, but they're not there yet.
Q: What's the biggest mistake teams make with agent reliability?
They test for success but not for failure. They test the happy path and assume the unhappy path will work. It won't. You have to deliberately break your agents to know they can recover.
Q: Does proof of continuity matter for simple agents?
If the agent is a single function call with no state, no. But as soon as the agent has multiple steps, external tools, or long-running tasks, you need continuity. The more complex the agent, the more critical it becomes.
Q: How does this relate to ai agents distributed systems architecture?
They're the same conversation. Agent systems are distributed systems. Once you accept that, the design patterns and failure modes are familiar. The continuity problem is just the distributed systems reliability problem, applied to AI.
Q: What's the one thing I should change in my current agent design?
Add idempotency keys to every external call. That single change will prevent the most common production failures. Do it before anything else.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.