What are background agents?

The name comes from the contrast everyone already feels. An agent in a chat window is a foreground agent: it works while you watch, it stops when you close the laptop, and its progress dies with the session. You’ll also hear “AFK agents” for the same 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.

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:

• Nothing survives. A dropped connection, a deploy, a rate limit, and the run is gone with all its progress.
• Nothing is bounded. A session spends until you notice. There’s no budget a runaway loop can hit.
• Nothing is recorded. When you ask “what did it actually do at 3am”, a scrollback buffer is not an answer.
• 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 the checklist is fairly stable across everything teams have learned since coding agents went mainstream:

• Durability. Runs checkpoint as they go. A crash or deploy resumes the run where it stopped instead of starting over.
• Isolation. Each unit of work runs in a fresh, isolated VM with its own kernel, destroyed afterwards. An agent with tools should not share a machine with anything you care about.
• Budgets. A hard spend cap per run, enforced by the platform rather than promised by the prompt. The right behavior at the cap is to pause warm and ask, keeping the work.
• Escalation. A defined place where “the agent needs a human” lands, so ten agents don’t mean ten browser tabs to check.
• The record. Every run answerable after the fact: what ran, what it read and wrote, what it cost, and who approved what.

Some of that list you can assemble from parts. Queues give you retries, containers give you some isolation, and a spreadsheet gives you cost tracking with a day’s lag. What resists assembly is the operational whole, one place where a run is durable, sandboxed, capped, supervised and auditable at the same time.

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.