What are AFK agents?

Where does the name come from?

AFK has meant “away from keyboard” since long before anyone ran a coding agent unattended. Developers borrowed it once agents got good enough to leave running, and “AFK agents” is the label that caught on in that corner of the community. We first heard the term from Matt Pocock (a developer educator who created Total TypeScript and teaches AI engineering at AI Hero), who helped popularise it as a named workflow for unattended coding agents. You’ll also see “background agents” for the same territory, and the two aren’t quite interchangeable. AFK names the supervision state: whether a person is watching. Background agent names the execution pattern: where and how the work runs. The same setup usually needs to satisfy both, but they’re answering different questions.

The safe-AFK test

AFK only tells you nobody’s at the keyboard. Whether it’s safe to leave one running is a separate question, and these five tests are how you answer it.

• Close the laptop. If the work stops when the lid does, you were supervising with extra steps.
• Kill the connection. A dropped connection or a rate limit shouldn’t end the run. If everything after that moment never happened, the run wasn’t durable.
• Hit the budget. Nobody’s watching the meter while you’re gone. Without a hard cap, a stuck loop’s failure mode is priced per token. At public API prices for an Opus-tier model (about five dollars per million tokens in, twenty-five per million out), a loop burning a few hundred thousand tokens on each retry runs a few dollars a pass, and a night of that reaches the low hundreds of dollars by morning.
• Require an approval. The run hits something it shouldn’t decide by itself. If it guesses instead of asking, or hangs until you happen to notice, the gate isn’t doing its job.
• Reconstruct the run afterward. “What the agent did while nobody was watching” needs an answer you can read. A terminal buffer on the machine it ran on doesn’t count.

A setup that fails even one of these can still look great in a demo. That gap between looking AFK and being safe to leave is why trust in unattended agents stays thin.

What being AFK requires

Going AFK safely means the runtime provides what your presence used to.

• Durability. Each stage checkpoints. A crash or a dropped connection sends the current stage back to its checkpoint, and the stages that already finished stay done.
• Scoped credentials. Each stage gets the access it needs for its job and nothing wider, so a bad prompt can only reach what that stage was already allowed to reach.
• Budgets. The cap is a real dollar amount you get billed, not credits you’d have to price out to know what a run can spend. What happens when a run reaches the cap was decided before it started: a hard stop, or a warm pause that holds the work done so far and asks a person whether to grant more. Either way, finished stages stay done.
• Gates. The decisions you’d want to make yourself stay held for you; the rest are judged against criteria you wrote down.
• An attention inbox. Everything that needs a person queues in one place with context attached, and subscriptions deliver those items where the team already works, Slack included.
• The record. Every run stays answerable after the fact: you can read back what it did and who approved the parts that needed a person.

Isolation is the one piece that isn’t standing in for something you did at the keyboard. It limits what any single stage can reach or leave behind. Each stage runs in a fresh, isolated VM with its own kernel, destroyed after, so nothing from one stage lingers into the next. You still trust the runtime; isolation keeps a bad stage from reaching past its own boundary.

From AFK sessions to AFK processes

Code is where this got named, because coding agents got good at working unattended first. The pattern doesn’t stay in code. The same runtime that runs a review panel unattended (several models reading one change before it merges) can put log triage on a schedule.

Take that log triage. It fires on a schedule and reads a fixed window, say the last hour of logs. It works through them and stops early if it reaches the spend you set. It files what it can classify with confidence and sends the rest to the attention inbox for a person to settle. Getting work onto a schedule or a trigger is its own decision, separate from what happens once it fires.

What makes that repeatable is deciding all of it before the agent starts: what triggers the run, the limits it works inside, the points where it stops for a person, and the output you expect back. On Sumn, that shape is a playbook: the process written down once, with the stages, models, budgets and gates named.