From "watch the chatbot type" to "wake me up when the PR is ready" — the persistence layer, the agent inbox, and the architectural shift that turned LLMs into colleagues you delegate to.
For the first three years of the LLM era, an "AI session" meant one thing: you typed, the model streamed tokens back, you waited and watched, then you typed again. That synchronous, turn-by-turn pattern is fine for 30-second answers. It is hostile to the kind of work people actually want to delegate — write the migration script, refactor that 4,000-line module, run experiments overnight, draft a 30-page report. Those tasks take hours, not seconds. Sitting there watching them stream is theatrical, not productive.
Sometime in late 2025, the industry collectively gave up on synchronous-only and shipped a different mental model. You hand the agent a task. It runs in the cloud, in its own sandbox, while you do something else. When it's done — minutes or hours later — it pings you. You review its work in an "inbox" that looks more like Linear than ChatGPT. This is what we now call async agents or background agents, and the architectural pieces that make it work are this lesson.
Analogy first. Sync agent is texting an assistant who holds the phone while they answer. Async agent is sending an assistant a task email — they pick it up, work on it from their desk, possibly delegate parts of it themselves, and reply when done. You are unblocked the moment you hit send. The whole productivity argument for AI agents — the part where one human directs ten of them — only works if the model is async.
Now precise. An async agent is an LLM agent whose execution is decoupled from the user's session. Three properties define it. (1) Persistence — every step of the agent's trajectory (LLM calls, tool calls, intermediate state) is checkpointed to durable storage so the run survives process restarts, network drops, and context compaction. (2) Out-of-band notification — the user is notified through a side channel (Slack, email, mobile push, an "inbox" UI) when the agent needs input or has finished. (3) Long horizon — runs are measured in minutes-to-hours rather than seconds, often spanning 50-500 LLM calls. The standard reference architecture has hardened around four primitives: a POST /runs that returns a run_id, a status poll at GET /runs/{id}, a webhook or inbox for human-in-the-loop interrupts, and a checkpoint store keyed by (thread_id, step). LangChain's open Agent Protocol (released August 2024, now the wire format under LangGraph Platform, Open SWE, and several third-party runners) codifies exactly these endpoints.
Cognition (the Devin team) coined a phrase that has become a useful unit of analysis: the async valley of death. It is the productivity dip you experience when delegating to an agent that runs for "too long to wait, too short to context-switch." A 30-second sync run is fine; a 4-hour run is fine (you go to lunch). Anything in the 3-15 minute zone is the worst — too brief to start something new, too long to stare at the spinner. The product solution is not "make the agent faster." It is to push runs past the valley with explicit handoff: the moment the agent starts, it sends you a "started" notification, and the moment it's done it sends a "review me" notification, and in between you do something else.
This is why every serious async agent product (Devin, Codex Cloud, Claude Code background runs, Cowork scheduled tasks) leads with Slack/Linear/email integration and not with a chat UI. The integration is the architecture.
Context window exhaustion. A 4-hour run can easily exceed any model's context. The KLong paper (Feb 2026, see Papers below) reports trajectories that grow to millions of tokens before completion. You need an explicit context-management policy — summarization, sub-agent delegation with bounded state return, file-system-as-memory — or the run dies when the prompt overflows.
Process death and resumability. A sync run can crash and the user just retries. An async run that crashes after 90 minutes of work has a real cost — you must be able to restart from the last good checkpoint. LangGraph's persistence layer was designed primarily for this; every node execution writes a checkpoint, and resuming a thread re-hydrates state up to that point.
Untrusted intermediate output. When the agent is running unsupervised, it has more time to drift. Anthropic's own internal review of agent failures attributes most user-visible regressions in long runs not to the model getting "dumber" but to compound error — early small mistakes become unrecoverable mid-trajectory because the agent never re-checked its assumptions. The standard mitigation is process reward models or verifier sub-agents that score each major step.
The shape that matters: everything to the right of the runner is async. The user is not in the loop on each LLM call. They show up once at start, optionally once or twice mid-run for a human-in-the-loop interrupt, and once at the end to accept the result. This is the architecture every serious 2026 agent product converges on.
karpathy/autoresearch as a working sketch of this idea (~66K stars within a month).simonw/research repo accumulated 13 separate research projects in two weeks, "averaging nearly one a day."SKILL.md-style script that runs on demand or on an interval, returning a notification when complete (this very lesson is generated by one). Claude Code background runs let you fork a run into a sandboxed worktree and resume later. Claude in Chrome can be left to drive a tab while you switch windows. The persistence layer under all three is the same checkpoint store; the cap on long runs is currently set by context-engineering rather than infra.
/goal command that loops until either the goal is verified complete or a token budget is exhausted — an explicit "spend N tokens trying" knob. Subagents let a Codex run spawn specialized children in parallel and collect their results. Mobile push notifications mean a run started on desktop can be reviewed on the phone — the canonical "delegated colleague" UX.
SKILL.md in a watched directory becomes a runnable async job, with the hub-and-spoke architecture (Day 14) keeping each spoke's working set small. Schedules are cron-like JSON files; runs write back into the workspace folder, which the user opens later. The downside is the operational story — there is no managed service; you are running it on your own machine, so persistence and recovery are your problem.
run_id, status (pending/running/interrupted/completed/failed), and trajectory.thr_47 in parallel and pick the best."step_84."(thread_id, step). Enables resume, fork, and replay.list_async_tasks."(thread_id, step) or by content hash? The latter lets you fork cheaply but breaks linear resume semantics."Three product/GTM takeaways:
Sync chat sells to "I want answers faster." Async agents sell to "I want my evenings back." Those are different economic buyers, with different ROI math. For botlearn.ai's enterprise pitch, the right framing isn't "Claude/GPT can answer your team's questions" — it's "Claude can run unsupervised against your training program overnight and hand your L&D lead an inbox of 8 things to review by 9am." The unit being sold is delegated time, not response speed.
Anyone can wrap a sync chat against a fine-tuned model. Almost nobody has shipped a credible inbox for agent work that fits an enterprise's existing review/approval flows. If botlearn.ai builds an inbox where managers triage agent-produced course outlines, learning paths, and assessment drafts, the surface itself becomes the product — and switching cost goes up sharply once managers' review muscle memory is calibrated to that inbox.
Sync chat naturally meters per token. Async agents naturally meter per run or per agent-hour — which, helpfully, is much closer to how enterprise buyers think about contractor or BPO spend. Replacing "0.5 cents per 1K tokens" with "$8 per agent-hour, capped" is dramatically easier to explain in a procurement meeting. For botlearn.ai's commercial motion, picking the right pricing primitive early is one of the few decisions that compounds.