An agent in a chat window is a foreground agent: it works while you watch, and it stops when you close the laptop, even after you’ve fought caffeinate and your power settings into submission. Its progress lives and dies with the session. You’ll also hear “AFK agents” for the opposite idea, and it’s the better mental picture: work that continues while you’re away from the keyboard.
A background agent flips every one of those properties. It starts from a trigger (a cron schedule, a webhook, a merge request opening) rather than a person typing. It runs somewhere durable rather than in a browser tab. And it ends by delivering something: a triaged incident, a reviewed change, a drafted report, plus the record of how it got there.
A fair test: if the work stops when you close your laptop, it wasn’t a background agent. It was you, supervising. Any developer can leave an agent running overnight. The difference between that and a background agent is the cage somebody built around it to keep it on track.
Why a chat session can’t just run longer
Teams usually meet the limit the same way: someone’s coding agent does great work for twenty minutes, so they try to hand it a job that takes all night, and it falls over. The model didn’t get dumber. A session was never a runtime:
- Recovery is you, by hand. Yes, you can resume a session or dig back through the history. But a dropped connection, a deploy or a rate limit still costs the run its working state, and stitching the work back together is a human job. Most people don’t know agent runs can be made durable, checkpointed and resumed like any serious workload, because a session can’t do it.
- The spend has no bound the run respects. You can cap a provider account, one provider at a time. There’s still no budget on the job itself, and a runaway loop spends happily inside the account cap until you notice.
- The record is a scrollback buffer. The history exists somewhere. But “what did it actually do at 3am” needs an answer you can hand to a teammate, and a terminal buffer on a machine that’s since rebooted isn’t one.
- One session is one reviewer. The panel patterns that make agent output trustworthy, like several models reading the same change blind, aren’t things a session does. You can build them by gluing tools together, and that glue becomes a system someone maintains.
- Escalation is you. The session’s only move when it’s unsure is to ask the person who isn’t there.
What the runtime has to provide
Running agents unattended is an infrastructure problem, and each requirement is there because of something that will happen, not something that might:
- Durability. Runs checkpoint as they go, and a crash or deploy resumes the run where it stopped. The reason is arithmetic: a run that’s alive for eight hours will meet deploys, rate limits and network failures as a matter of schedule, and without checkpoints every one of them reprices the whole run.
- Isolation. Each unit of work runs in a fresh, isolated VM with its own kernel, destroyed afterwards. The reason is that instructions bind the model, not the machine: a prompt can be talked out of its rules, a kernel boundary can’t. An agent with tools shouldn’t share a machine with anything you’d mind it reading.
- Budgets. A hard spend cap per run, enforced by the platform rather than promised in the prompt, checked before each call. The reason is that a promise degrades over a long run and a comparison of two numbers doesn’t. The right behavior at the cap is to pause warm and ask, keeping the work.
- Escalation. An agent inbox: a defined place where “the agent needs a human” lands. The reason is that attention is serial: ten agents can’t mean ten browser tabs, or the agents aren’t background, you are.
- The record. Every run answerable after the fact: what ran, what it read and wrote, what it cost, who approved what. The reason is that trust in unattended work is retrospective. You extend it next week based on what you can verify from last week.
Some of that you can assemble from parts, and plenty of teams do. Queues give you retries. Containers give you decent isolation. Cost tracking is a script and a spreadsheet, checked the next morning. What never quite arrives from parts is all of it on the same run at the same time: this run, checkpointed, in its own VM, under its own spend cap, with its own escalation path and its own receipt. That combination is the difference between an agent that runs at night and an agent you stop thinking about at night. Whether a given setup has it comes down to nine questions you can ask before the agent touches production.
Where playbooks come in
The last piece isn’t infrastructure, it’s repeatability. A background agent that does a job once is a demo. The valuable version is the process your team runs every night or on every merge request, written down precisely enough that it runs the same way each time: which steps, which models, what gets judged automatically and what waits for a person.
On Sumn that written-down process is called a playbook, and it’s the unit everything else attaches to: versioning, budgets, gates and receipts.