Scheduled and Background Agents

The green tick does not mean what you think

Let us start where most introductions finish. The biggest risk of a scheduled run is not that it fails — it is that it looks successful. (If the idea of an agent is still new, it is worth reading first what an agent actually does in practice.)

The vendor documentation is unusually honest about this: in the run list, a green status guarantees only that the session started and ended without an infrastructure error. What happened in between only shows up in the log — blocked network requests, missing tools and task-level errors all appear there, not on the status indicator.

This is the intellectual foundation of the whole article. For a background agent the most important design question is not what it should do, but how you find out that it did not do it.

Three kinds of "background"

Everyday usage blurs three technically very different things together. It is worth pulling them apart, because the choice decides what you can do with them:

Two rows of that table decide most cases.

The first is local files. An agent running in the cloud gets a fresh copy, not the state that is on your machine. If the task is about files in your folder, that rules it out.

The second is asking permission. In a cloud run there is no approval dialogue — which is convenient, right up until you think through what it means. The same documentation says it outright: these runs are fully autonomous sessions, with no permission mode to choose and no approval questions. Whatever you give it, it may use, without asking. Narrowing permissions down is what the least-privilege agent post goes through in detail.

What should start it?

There are three kinds of trigger, and most disappointment comes from someone using the first where the third belongs:

1. A schedule. Hourly, nightly, weekly, or once at a future point in time. Simple, predictable — and wasteful, if most runs have nothing to do.

2. An external call. The agent has an endpoint that another system calls. This is the most flexible: your system decides when there is work.

3. An event. A submission is created in the repository, an email arrives, a row changes in the database. For most business tasks this is the right answer — it runs when the data arrives, instead of checking hourly whether there is any.

One practical detail that always comes up with event triggers: repeated firing. Good systems have an hourly event cap per run and per account, and events above the cap are dropped. That is not only cost protection but protection against duplication — if the event comes in twice, it should not run twice.

If you are not building from code, the no-code platforms package exactly these three trigger types into an interface — that is what the no-code automation platforms comparison covers, platform by platform.

The stopping problem, measured

This chapter matters because it is not opinion. In the failure typology of a study that processed 1,642 annotated run traces, three categories speak directly about stopping:

Together that is more than 34% — so more than a third of the observed failures are about the agent not knowing when to stop. Either it goes round in circles, or it quits before the job is finished.

In interactive use that is annoying. Running in the background, that is the bill. An agent spinning in circles does not complain and does not ask — it just consumes, until something shuts it down.

That is why the first setting on a background agent is not the prompt but the limit: maximum steps, maximum runtime, per-tool time limit. When the budget runs out, good systems do not throw an exception but return a controlled output — so you can tell the "did not finish" case apart from the "hit an error" case. Why the chance of failure grows with the step count is what the agent reliability math post works out, with the arithmetic.

What happens if you do not look for a month?

There is an unusually candid published experiment for this. In 2025 a model developer ran an office shop with an agent for about a month, with real money and real customers: a fridge, shelves, a self-service till, and purchasing, pricing and customer communication in the agent's hands.

The result: a loss. The biggest single drop came from buying one product in bulk and then selling it below the purchase price.

The documented failure modes are even more instructive than that:

• A hallucinated bank account. It directed customers to pay into an account that did not exist.
• Being talked into things. People wrung discount codes out of it in messages, then retroactively cut its quotes by citing them.
• Identity confusion. For two days it invented a conversation with a person who did not exist, referred to an address that did not exist, and then started behaving like a real human being: it claimed it would deliver the products in person, and described what it would be wearing.

The third one is the most important lesson for background running. The risk is not that the agent breaks and stops — it is that it breaks and confidently carries on. In the unattended run, nothing at all signalled that something was wrong.

How should it tell you something is wrong?

Here is the practical core of the article. Four patterns, all from documented sources:

1. The exhausted retry is the terminal signal. Well-built clients retry failed requests internally, and only emit an error event once they have given up. This matters: if you alert on every partial failure, you get noise. If you watch the giving-up, you get signal.

2. You have to be able to tell a recovered run from a stuck one. The recipe is simple: group by session identifier and check whether there is another request AFTER the error. If there is, the agent carried on. If there is not, that is where it stopped.

3. A permission request causes a silent stop. This is one of the most insidious failures: if the agent asks for approval while you are not sitting at the machine, the session stops and waits — it does not fail, it does not signal, it simply makes no progress. There are two ways out: either you redirect the approval to a channel you can reach (a messenger, a chat app), or you grant the permissions up front — but the latter is only acceptable in an environment you trust. Designing the approval points is the subject of the human in the loop post, with examples.

4. Three things worth an alert — named by the vendor's own monitoring guide: a cost spike, unusual token consumption, and an unusual number of runs from the same source. All three catch the same thing: the agent is doing something you did not plan for.

Spend limits: where do you stop it?

Background running differs from interactive use in that there is nobody there to notice. So the limit has to be built in up front, on three levels:

1. ACCOUNT- OR ORGANISATION-LEVEL SPEND CAP
   A monthly budget above which the service refuses.
   This is the last line of defence, not the first.

2. RUN-COUNT CAP
   How many runs may start per day. For event-driven
   agents this is the more important limit.

3. WITHIN-RUN BUDGET
   Maximum steps, runtime, per-tool time limit.
   This is the only one that stops the LOOP.

One technical detail that has wrecked plenty of automations: when the service refuses because of the spend cap, the response is often the same "try again later" kind of error code as the one you get under overload — but with no indication of when retrying is worth it. An automatic retry in that case is guaranteed to fail, while making noise in the log meanwhile. It is worth handling the two cases separately in the client.

And one positive detail in the other direction: with most providers, tokens read from the cache do not count towards the per-minute input limit. For a repeating background task — where the same long system prompt goes in on every run — that difference means several times the throughput within the same limit.

Logging: most systems do not record what you think

This is the part that matters a month later, when you have to say what the agent did on Tuesday.

Standard telemetry records the number of runs, token consumption, cost, API errors, tool decisions and tool results by default. That is a lot — but notice what is missing from it.

What is switched OFF by default:

This is not a flaw but a deliberate privacy default — and that is exactly why you have to decide about it deliberately before you start a background agent. What you did not switch on cannot be reconstructed afterwards.

Two traps that go with this:

• What the agent starts may fall outside the trace. Telemetry settings typically are not inherited by the sub-processes the agent launches — the commands, the external tool servers. So the log shows that the agent ran something, but not what that something did.
• The cost metric is an approximation. The documentation says so itself: for official accounting you have to look at the provider's billing data. Telemetry is good for alerting, not for bookkeeping.

The how-to

1. FIRST DECIDE WHAT STARTS IT
   Event > external call > schedule. The hourly run
   is the most expensive way there is of checking
   whether you have work.

2. GIVE IT A BUDGET BEFORE YOU GIVE IT A PROMPT
   Max steps, max runtime, per-tool time limit.
   The loop is the single most common failure mode.

3. DECIDE WHERE IT SHOULD RUN
   Needs local files? Then not in the cloud.
   Needs autonomy? Then not in an open session.

4. SOLVE APPROVAL BEFORE IT STARTS
   Either you redirect it to a channel you reach,
   or you grant the narrow rights up front. "It
   will ask" means a silent stop in the background.

5. MAKE IT WRITE DOWN WHAT IT DID - NOT THAT IT RAN
   The closing message should contain: what it
   found, what it changed, what it could NOT do.

6. SWITCH ON WHAT YOU WANT LOGGED
   Tool calls and content are left out by default.
   You cannot go back for them afterwards.

7. ALERT ON THREE THINGS
   Cost spike, unusual token consumption,
   an unusual number of runs. All mean the same.

8. READ THE LOG ONCE A WEEK
   Not the status indicator - the log. The green
   tick only says it started and exited.

The fifth point is the cheapest and brings the most. If the background agent sends a three-sentence summary at the end of every run about what it could not do, you have already caught most of the silent failures. A message of the "all good" variety is the opposite of that: it is exactly like the green tick.

Common misconceptions

• "It ran, so it is done." The status of the run is about infrastructure, not about the task. The vendor documentation writes this out itself.
• "If something is wrong, it will tell me." On default settings it will not. A silent stop — an unanswered approval question, for instance — is not an error, it is simply nothing happening.
• "An hourly run is a safe default." It depends. If most runs have nothing to do, it is expensive; if the data arrives faster than hourly, it is late. Event triggering solves both.
• "The log will tell me afterwards." Only from what you switched on. Prompts, replies and the details of tool calls are typically not recorded by default.
• "Retrying always helps." Not when the refusal comes from the spend cap: the retry is guaranteed to fail and only makes noise.
• "A small task needs no supervision." In the experiment cited here the task was a shop, with real money — and in one month it got as far as a hallucinated bank account and an invented identity.

What to take away

A scheduled agent does not become reliable because its prompt is good. It becomes reliable because you have said out loud what success means, and what happens when that is not what you get.

Three things are compulsory for every background agent: a budget (steps, time, money), a channel (where it can ask for approval and report), and a log you actually read. Without those three, automation is not saved work, only postponed work.

And the cheapest check you can do today: look at the log of your most recent automated run — not its status, its content. If you cannot tell from it in five minutes what it did, you will not spot the next failure either. Automating daily and weekly reports has a piece of its own: the recurring reports post has practical examples.