Background agents: AI that finishes the job after you close the tab

The frontier question for AI agents is no longer how smart one reply is — it's whether a multi-hour agent run survives a timeout, a crash, or a failed step three hours in. That's not a model problem. It's an infrastructure problem, and the answer the whole industry landed on in 2026 has a name: durable execution. If your agent does real work, it belongs in a background workflow that can be checkpointed, retried and resumed — not in a long HTTP handler waiting for the user to keep the tab open.

Why this matters now

Agents got dramatically more patient this year. METR, which measures how long a task an agent can complete autonomously, found the length of work a frontier model can reliably finish is doubling roughly every four months — up from a seven-month doubling time over the prior six years. As of early 2026, the top model on their board hit a 50%-time horizon of about 14.5 hours: a task that would take a skilled engineer most of a working day, done autonomously — with coin-flip reliability.

Sit with that second number. At the edge of what an agent can do, it succeeds about half the time. Long work plus ~50% reliability is precisely the combination that breaks the synchronous, request-response model most apps are built on. You cannot ask a user to hold a browser tab open for fourteen hours and hope the process doesn't die. You need work that can fail, retry, and pick up where it left off.

The synchronous trap

The default way teams first wire up an agent is the way that breaks:

• HTTP and serverless timeouts kill the request long before a real agent task finishes.
• A crash loses everything. Restart and the agent starts over from zero, re-spending every token it already spent.
• No retries. One flaky tool call — a rate limit, a 500 from an upstream API — fails the entire run.
• Human approval stalls it. The moment an agent needs a person to say "yes, ship it," a synchronous handler has nowhere to wait.

Every one of these is an infrastructure gap, not a model weakness. A better model doesn't fix them. A better runtime does.

What durable execution actually does

Durable execution persists the agent's state to a database at every step. If the machine crashes, the workflow resumes from the exact step before the failure — not from the beginning. Retries, timeouts, pauses for human approval, and deterministic replay come built in. The mechanism is simple to state and hard to get right:

Every step is a checkpoint. Progress is never lost, because the state to resume it is already written down before the step runs.

This is why 2026 shipped durable execution nearly everywhere at once. AWS released Lambda Durable Functions (December 2025), Cloudflare took Workflows to GA, Vercel launched its Workflow DevKit, and Microsoft updated its Durable Task for AI agents in April 2026. The common thread the vendors themselves cite for the surge is AI. Durable execution crossed from niche to default because agents made long, failure-prone, multi-step work the normal case.

When you need it — and when you don't

You want a durable background workflow when:

• The task can run longer than a request timeout (anything past ~30–60 seconds).
• A human has to approve or intervene mid-run.
• The agent chains several tool calls, any of which can fail transiently.
• Losing the work halfway would be expensive — in tokens, in time, or in a half-completed side effect.

You don't need it for a single sub-second model call that returns a chat response. Don't wrap a simple completion in a workflow engine; that's ceremony. The line is whether the work outlives a single request.

Our opinion

Stop treating the model as your reliability layer. It isn't one — at the frontier of its ability it's a coin flip, and no amount of prompt tuning changes that. Reliability comes from the system around the model: the checkpoints, the retries, the idempotent steps, the durable state. The teams whose agents feel dependable in production aren't running smarter models than everyone else. They're running the same models inside a workflow engine that assumes failure and recovers from it.

Put plainly: ship agents as durable background workflows, not as long HTTP handlers. It's the same shift we described in the delegation gap — the hard part of agentic AI isn't getting the work done once, it's running it reliably, over and over, in production.

How Ashvara helps

We build the backend that agents run on — the queues, the durable workflows, the idempotent step design, and the boring, reliable state layer underneath. We're firm believers that most of this belongs on infrastructure you already trust; see just use Postgres for how we think about the persistence layer that durable execution leans on.

If you're moving an AI feature from a working demo to something that survives real traffic and real failures, that's exactly the jump our backend & API development work is built for. Tell us what your agent needs to do and we'll design the workflow so it finishes even when steps don't — start a conversation.

Source: METR, "Task-Completion Time Horizons of Frontier AI Models" (metr.org/time-horizons), 2026.