Background Agents: Running AI Agents 24/7 Without You at the Keyboard

In 2026, Stripe reported that its internal background coding agents were producing more than 1,300 merged pull requests every week, reviewed by humans but with no human-written code. That result matters beyond software: it shows what changes when AI work moves off a chat screen and onto an always-on machine. A chat assistant stops when you close the tab. Background agents keep working.

A background agent is an AI agent that runs on its own cloud machine, starts from a schedule, event, or message, completes a task without constant supervision, and reports the result when it is done. This guide explains the runtime model, the controls it needs, and the business work it can handle beyond code.

What is a background agent?

A background agent is defined less by its model than by its operating environment. It runs remotely, persists after your laptop sleeps, and can wake up without a fresh prompt from you. Five properties distinguish it:

• Remote runtime: work happens on a cloud machine, not inside your browser tab.
• Automatic triggers: a schedule, webhook, inbox event, form, or message starts the run.
• Asynchronous execution: you delegate the task and return later.
• Persistent state: the system remembers progress, context, and previous runs.
• Results and escalation: it delivers an artifact, notification, or approval request.

This is related to autonomy, but it is not the same subject. Our guide to how autonomous AI agents make decisions covers planning and decision-making. This article owns the separate question of when and where the work runs.

From in the loop to on the loop

With a chat assistant, the person is in the loop for almost every step. You prompt, inspect, correct, and prompt again. With background AI agents, the person moves "on the loop": you define the goal and boundaries, then review outcomes and exceptions.

Delegation does not remove human control. It moves control from continuous steering to clear instructions, observable runs, and deliberate approval points.

That shift is the practical value. The system handles waiting, repetition, and routine tool use. People keep judgment and authority.

Background agents vs chat assistants vs coding agents

The difference is the runtime, not a more magical model.

Background coding agents are the best-known example because code has measurable outputs: tests pass, builds succeed, and pull requests can be reviewed. The same operating pattern can manage business work when the task has a clear definition of done.

How background agents work

A useful background system combines runtime, triggers, state, tools, and reporting. Remove any one of them and the experience becomes fragile.

A dedicated machine that does not sleep

The agent needs a place to run after your device is off. Each serious background system runs work in a separate remote environment rather than tying execution to an open browser tab. For business work, the same principle means an isolated cloud machine with enough time and permissions to finish the job.

The machine is not a minor hosting detail. It is the foundation of 24/7 execution. A prompt stored in a database cannot do anything by itself. A live runtime must receive the trigger, load context, call tools, handle errors, and save the result.

Triggers: schedules, events, and messages

Scheduled AI agents can run every weekday at 8:00, every Friday afternoon, or once at a future date. These recurring agent runs remove the need for someone to remember and restart the work. Event-triggered agents react to a new email, CRM record, form submission, payment failure, support ticket, or webhook. Message triggers let a teammate start work from Slack or another channel.

A trigger should carry enough context to make the run deterministic: what happened, what record changed, what output is expected, and which policy applies.

Memory and state across runs

Long-running agents need checkpoints. If a research run has examined 80 of 100 companies before an API fails, it should resume at company 81 rather than start over. Persistent state also prevents duplicate emails, repeated alerts, and lost approvals.

State is not unlimited memory. Good systems store the task status, relevant facts, tool outputs, timestamps, and a trace of decisions. They expire or refresh stale information rather than treating every past fact as permanently true.

Tools and connections

A background agent without access to real tools is an interesting demo. Useful work requires scoped connections to inboxes, CRMs, documents, databases, analytics, billing systems, or APIs.

Permissions should match the task. A reporting agent may only need read access. An invoice-follow-up agent may draft a message but require approval before sending it. Least privilege makes the system safer and easier to audit.

Reporting back and asking for approval

The final step is not always "done." It may be a summary, changed record, downloadable file, dashboard update, or request for a human decision. Proactive notifications should surface exceptions, not generate a stream of noise.

A good background agent can pause before an irreversible action, explain what it plans to do, and resume from the same point after approval.

Proof the model works in production

Software teams provide unusually public evidence for asynchronous agents. In Part 2 of its Minions report, featured below, Stripe reported more than 1,300 merged pull requests per week, reviewed by humans but containing no human-written code. Spotify Engineering reported more than 1,500 merged pull requests from its background coding agent, Honk. Ramp reports that about 30% of pull requests merged to its frontend and backend repositories are written by Inspect, its internal background agent.

Minions: Stripe’s one-shot, end-to-end coding agents—Part 2Minions are Stripe’s homegrown coding agents, responsible for more than a thousand pull requests merged each week. Though humans review the code, minions write it from start to finish. Learn how they work, and how we built them.stripe.dev

These numbers do not prove that every business process should become agentic. They prove the operating model: remote execution, bounded access, measurable output, and human review can turn a request into completed work at scale.

Engineering went first because tests make success visible. Operations teams need equally concrete acceptance criteria: a reconciled report, a qualified lead list, a clean CRM field, or an approval-ready draft.

Background agent use cases beyond code

The strongest use cases follow a simple pattern: trigger → task → output.

Daily briefings and reporting

• Trigger: every weekday at 7:30
• Task: pull metrics from analytics, billing, and CRM tools; compare them with yesterday
• Output: a short briefing with anomalies and source links

Instead of rebuilding the same dashboard each morning, the team receives the interpretation and can inspect the underlying data.

Monitoring and alerts

• Trigger: an hourly or daily schedule
• Task: check competitor pages, prices, search rankings, mentions, inventory, or uptime
• Output: notify only when a defined threshold or meaningful change appears

The agent absorbs the repetitive checking. Humans receive the exception.

Inbox triage and CRM upkeep

• Trigger: a new message or lead arrives
• Task: classify intent, enrich the contact, find the matching account, and prepare the next action
• Output: a routed conversation, updated record, and suggested reply

This differs from a chatbot. The system works across tools and leaves the operational record cleaner than it found it.

Overnight lead research

• Trigger: a list is added before the end of the day
• Task: research each company, verify fit, capture evidence, and score priority
• Output: a qualified list waiting the next morning

Content and SEO operations

• Trigger: a weekly audit or daily editorial schedule
• Task: inspect performance, check published coverage, identify gaps, and prepare a brief
• Output: prioritized actions with sources, not a generic list of ideas

Recurring administration

• Trigger: an overdue invoice, Friday status cycle, or monthly close
• Task: collect evidence, draft follow-ups, reconcile fields, and flag exceptions
• Output: an approval queue or completed low-risk updates

{ "goal": "Prepare a daily operations briefing", "trigger": "Weekdays at 07:30", "inputs": ["analytics", "billing", "CRM"], "steps": ["compare the last 24 hours with the previous period", "identify material changes", "link every claim to its source"], "guardrails": ["read-only access", "never message customers", "ask for approval if data conflicts"], "output": "A five-minute briefing with metrics, anomalies, and recommended actions" }

When a background agent is the right choice

Use one when the task is repetitive, has a reliable trigger, draws from accessible data, and has a clear finish line. The best early tasks are frequent enough to matter but safe enough to inspect while you learn.

Avoid autonomous execution for vague strategy, emotionally sensitive communication, legal judgments, or any action where one error creates disproportionate harm. An agent can prepare evidence and a draft without owning the final decision.

A safety checklist

• Start with read-only access where possible.
• Define a concrete success condition.
• Limit each connector to the permissions required.
• Keep a log of tool calls and outputs.
• Add approval before payments, deletions, publishing, or external messages.
• Define retry limits and an escalation path.
• Test failure cases with sample data.
• Review false positives before expanding scope.

Zapier, Make, and n8n are useful when the process is a stable flowchart: if this happens, move that field. A background agent is better when the path changes according to the evidence it finds. The tradeoff is that probabilistic work needs stronger observation, boundaries, and approval controls.

How to choose a background agent setup

Ask these questions before choosing a product or building your own:

1. Does it run when my device is off? "Background" should mean remote, persistent execution.
2. Which triggers does it support? Look for schedules, events, webhooks, and messages.
3. Can it use my actual tools? Count usable, permissioned connections rather than logo walls.
4. Does it preserve state? Failed runs should resume safely and avoid duplicates.
5. Can it stop for approval? Human-in-the-loop must block the action, not merely send a notification.
6. Is the environment isolated? Understand where data, credentials, files, and logs live.
7. Can I inspect what happened? A result without a trace is a black box.
8. How is it priced? Include model usage, runtime, infrastructure, and retry costs.

Developer products such as Cursor, Codex, Jules, and Copilot are optimized for repositories and code review. Business tasks need email, CRM, documents, scheduled runs, and operational approvals.

If you want to assemble the runtime yourself, read our guides to deploying an AI agent step by step and self-hosted AI agents. Those articles own the deployment and infrastructure decisions that this guide intentionally leaves out.

July 29, 2026

How to Deploy AI Agents in Production: A Step-by-Step Guide

A governance-first, step-by-step guide to deploying AI agents in production, plus the four pillars that separate a demo from an agent you can trust: approvals, observability, least privilege, and secure hosting.

A first-hand scheduled run

This article itself began as a scheduled Rerun coworker run at 04:00 UTC. The coworker fetched 93 published blog URLs, checked recent pillar history, rejected a vertical because its monthly quota was already used, and selected this P3 topic from live Search Console signals and cached keyword data. It then created a draft and sent the preview through an SEO quality gate. The first review scored 8.2/10, so publication stopped while incorrect source details and a broken link were fixed.

That is the operational pattern in miniature: a schedule starts the task, tools gather evidence, state preserves the draft, a quality gate blocks a weak result, and the run continues after correction. The useful output is not merely text. It is a traceable result with sources and a visible stop condition.

Running background agents with Rerun

On Rerun, AI agents are called coworkers. You can pick a ready-to-run coworker from the library or build your own, connect the tools it needs, and give it a schedule. Each coworker runs 24/7 on its own private cloud machine, so work continues when your laptop is closed.

Rerun is not another chatbot that waits for your next message. It is not a Zapier-style flowchart that you must wire and maintain. You can watch the coworker work, inspect its tool calls and logs, and place a real approval gate before consequential actions.

That operating layer matters more than a flashy demo. Always-on work needs visibility when it succeeds, a clear explanation when it fails, and a person in control when judgment is required.

The useful distinction is operational

A model can produce a smart answer in a chat window. A background agent can take responsibility for a bounded result while you are elsewhere.

Start with one recurring, measurable, low-risk task. Give it scoped access, an explicit definition of done, and an approval step before anything irreversible. Then inspect the runs. The goal is not to remove people from the loop. It is to stop making them sit at the keyboard for work a dependable system can finish in the background.