Background Agents: AI That Works While Your Team Sleeps

The inbox that fills while nobody is looking

A support team in Manchester logs off at six. Overnight, 140 tickets arrive from customers in other time zones, a supplier sends revised price lists, and the payment processor posts a batch of failed transactions. At nine the next morning, the first two hours go on sorting before anyone does anything useful.

Background agents are the obvious response, and one of the clearer agentic AI trends of the year. Instead of a chat window where someone asks and waits, the agent runs unattended on a schedule or trigger, works through a queue, and leaves prepared work for a person to check. It is less exciting than a talking assistant and considerably more useful.

What makes an agent a background agent

The model and tools are the same as any other agent. What differs is the operating context, and that changes the design.

• No one to ask. An interactive agent can check with the user. A background agent must either decide within its rules or park the item for review.
• Triggers, not prompts. It starts on a schedule, a new file, a webhook or a queue reaching a certain size.
• Long runs. Jobs may take hours and must survive a failed API call or a restart halfway through.
• Outputs for humans later. The deliverable is usually a draft, a proposed action or a report, not a conversation.

Software developers met this pattern first, with coding agents that pick up an issue, work on a branch and open a pull request for review. The same shape works for operations teams.

Good jobs for overnight agents

• Triage and draft replies for support tickets that arrived out of hours, grouped by urgency
• Match bank and payment-processor transactions to invoices and list the ones that do not reconcile
• Read supplier price-list changes and flag products where margin has dropped below a threshold
• Research new leads against public information and the CRM, and prepare a summary for each
• Review yesterday's orders for anomalies such as unusual quantities or mismatched addresses
• Check that scheduled content, stock feeds or reports actually ran and explain any failures

Notice what they share. Each produces something for a person to act on, and each involves reading and judgement across several sources, which is where agents beat plain scripts. If a task is fixed and rule-based, a scheduled script is cheaper and more predictable; we would not wrap it in a model for the sake of it.

Designing for an unattended run

The morning should bring results, not surprises. That depends on a handful of engineering choices made before the first run.

1. Hard limits. A maximum number of steps per item, a spend cap per night and a wall-clock timeout.
2. Idempotency. If the job restarts, it must not reply to the same customer twice or post the same journal twice.
3. Checkpoints. Progress saved per item, so a failure at item 300 does not repeat items 1 to 299.
4. A review queue. Every proposed action lands in a list with the agent's reasoning and the evidence it used.
5. A summary. A short morning report: items processed, items parked, errors, cost.
6. Alerting. Someone is told if the run did not happen, stopped early or spent far more than usual.

An agent that fails loudly at 2am is an inconvenience. One that fails quietly and looks finished is a problem you discover from a customer.

What should never run unattended

Some actions need a human in the loop no matter how well the agent performs in testing. We keep these behind approval by default:

• Sending anything to a customer, supplier or regulator
• Moving money, issuing refunds or changing payment details
• Deleting or overwriting records
• Changing prices, stock levels or permissions in live systems

Once there are months of logs showing the agent's proposals being accepted without edits, some low-risk categories can move to automatic. That decision should be based on evidence, and reversible. Our post on human-in-the-loop agent design goes into how to set those thresholds.

What background agents cost

The running cost is model usage plus a small amount of compute and storage. For a queue of a few hundred items a night with modest context, that is usually a modest monthly figure, far less than the staff time involved. The bigger costs are the build, the integrations with each system the agent reads, and ongoing monitoring.

A rough illustration: an agent triaging 150 overnight tickets and saving a team 90 minutes each morning is worth roughly 30 hours a month. If the build is a six-week project, the payback depends mostly on whether the drafts are good enough to accept with light edits. Measure that acceptance rate from week one. Our breakdown of what a custom AI agent costs covers the build side.

How we build them

SpiderHunts starts with the review queue, not the agent. If the team cannot see, accept and correct what the agent produced in under a minute per item, the rest does not matter. We then build the tools, run the agent in shadow for two or three weeks while people still do the work, and compare. Only after that does the team start its day from the agent's queue.

The infrastructure is dull on purpose: a job queue, a scheduler, a database of runs and a dashboard. That is the part of our automation work that keeps an agent supportable a year after launch.

Frequently asked questions