Background AI jobs: a safety card for schedules, stop controls and fallback

The most dangerous background job is not always the one that crashes. It can be the job that looks green, repeats the same write three times, and sends the same email to three customers before anyone notices.

An AI job that keeps working after you leave the screen needs more than a schedule. It requires a run card: who owns it, what may trigger it, how many attempts it gets, how to stop it, and how the work continues manually.

Use the card for recurring reports, inbox checks, meeting follow-ups, and other work that should run without constant supervision. Fill in one card per job before turning on the schedule.

What is a background AI job?

A background AI job is a bounded run that continues on a server or starts from a schedule or event without a user keeping a chat or browser connection open.

Google and Perplexity document the same basic pattern: start the job, store its identifier, and retrieve its status later. The run can continue when the client disconnects. That solves the connection problem. It does not settle who is accountable for the result.

Source: Google AI for Developers – Background execution

Source: Perplexity – Background Mode

A technically completed job is not automatically an accepted job. The report may be stale. The draft may have the wrong recipient. A successful API write may have created a duplicate.

Separate trigger, run, and acceptance

Automations become hard to debug when everything is described as one event: "the AI runs every morning." Split the job into three decisions instead.

• The trigger decides when and why the job starts.
• The run defines which data, tools, attempts, and costs are allowed.
• Acceptance decides whether the result may be used, sent, or written back.

Grok Automations shows why the trigger needs its own contract. A job can start on a calendar or from an incoming email, with sender, recipient, or subject used as a filter. An email is also external content. Treat it as input, not as a trusted instruction.

Source: xAI – Automations in Grok

Always record where the trigger came from: schedule, approved sender, manual test, or another system. Add a unique run key, such as job name + scheduled time + input version. If that key has already been accepted, a later delivery must not repeat the write operation.

The safety card for a background job

Copy these fields into your working document. One card should cover one job, one owner, and one clear destination.

1. Name, owner, and definition of done

• Job: The exact task, without phrases like "help with administration."
• Owner: The person or role that receives alerts and can pause the job.
• Done: The observable result required before the run can be assessed.
• Accepted: The quality threshold the result must pass before use.

"Create the weekly report" is too vague. "Create a draft with five fixed headings, link each metric to its source, and place the file in the review folder" can be tested.

2. Trigger and duplicate protection

• Allowed trigger: Exact schedule, timezone, sender allowlist, or system event.
• Run key: A unique value that follows the job through the workflow.
• Duplicate check: Where the system checks whether that key has already run or been accepted.
• Concurrency: Whether a new run may start while the previous one is still active.

Test daylight saving changes, delayed deliveries, and the "run now" button. If two triggers can arrive together, choose whether to queue, reject, or merge them. Do not leave that choice to the model.

3. Budgets for time, attempts, and actions

• Maximum runtime: When the job should cancel or escalate.
• Attempt budget: How many retries are allowed and which failures qualify.
• Cost ceiling: Model, tool, and runtime spend per job and per period.
• Action budget: Maximum files, records, recipients, or writes per run.

Perplexity documents that Agent API Skills use a durable runtime and recommends background execution for skill work. This makes long document jobs practical, but the cost and number of steps still need a ceiling.

Source: Perplexity – Agent API Skills

Three retries are not three free chances. If the first attempt sent an email before the response disappeared, the next attempt may create a duplicate. Make write steps idempotent: the same run key should produce the same final state, not another side effect.

4. Status you can trust

Store at least the run ID, trigger source, start time, workflow version, and last known status. Then translate the provider status into your own business status.

• Running: The job is working or waiting for approval.
• Technically complete: The provider reports completion.
• Aborted or incomplete: The result must not move forward.
• Accepted: A check confirms that the definition of done and quality threshold were met.

Anthropic's Agent SDK marks deliveries from scheduled tasks as scheduled-trigger and interrupted assistant messages as aborted. Those small fields matter: a truncated message must not be mistaken for a finished answer.

Source: Anthropic – Claude Agent SDK TypeScript v0.3.214

5. Four levels of stop control

A stop button that only closes the screen does not stop a job continuing on the server. Record who may use each level and how the team verifies that it worked.

1. Pause new triggers so the queue stops growing.
2. Cancel the active run and follow its status to a terminal state.
3. Revoke tools or connections if the job keeps causing harm.
4. Switch to the manual fallback for work that cannot wait.

Google and Perplexity expose separate cancellation calls for active background runs. Perplexity also describes cancellation as asynchronous: a cancelling response means you must keep checking until the job reaches cancelled.

Source: Google AI for Developers – Background execution

Source: Perplexity – Background Mode

6. Evidence log and alerts

The log should let a person explain what happened without collecting unnecessary sensitive content. Store:

• run key and workflow version
• trigger source and time
• references to inputs, rather than plaintext secrets
• tools and write actions
• attempt count, duration, and cost
• final status, check result, and approver

Alert the owner when the job exceeds time or cost, requires action, is cancelled, fails repeatedly, or reaches its action budget. An alert with no named recipient is just another log line.

7. A fallback that has been tested

Write down how the task is done if the AI job stays off for a day. State where the inputs live, who takes over, and how duplicate work is prevented when automation returns.

Test the fallback before the pilot depends on it. Pause the trigger, complete one run manually, and restart without processing the same item twice. If recovery depends on context held only in one person's head, the fallback is not ready.

Preserve the last stable result

Manus Auto-Publish uses a control that more background jobs should borrow: failed or in-progress builds do not replace the last stable website version. Automatic publishing starts off, can be cancelled, and only runs after the user explicitly enables it.

Source: Manus – Introducing Auto-Publish

For other workflows, this means keeping the last accepted report, contact list, or data version in place until the next result passes its checks. Write to a new version first. Move the pointer or status after acceptance. A failure then causes a missed update rather than destroying the working version.

Measure accepted work, not green runs

OpenAI proposes classifying AI work as "ready to use," "needs correction," or "needs escalation." For a background job, that tells you more than the provider's green status.

Source: OpenAI – A scorecard for the AI age

Track at least four measures during the pilot:

• percentage of runs accepted without correction
• minutes spent on human review and rework
• full cost per accepted result, including retries
• duplicate, late, and manually recovered runs

A Manus customer story describes Ascendea keeping repetitive scheduled work in narrow local agents, routing exceptions upward, and retaining human review before CRM writes. Its performance figures are vendor and customer claims, not an independent benchmark. The architecture is still useful: do not combine expensive judgment and routine repetition inside the same unattended job.

Source: Manus – Ascendea customer story

A sensible first background job

A weekly report is often a better pilot than an agent that replies to customers or publishes changes. Let it read named sources, create a versioned draft, and alert when data is missing. A person accepts the report. The manual fallback is already familiar.

After the card works, try an inbox check that classifies messages and drafts replies without sending them. Delay payments, permission changes, deletion, binding customer answers, and automatic publishing until stop, recovery, and negative tests have been proven in a safer environment.

If you have a recurring task but no run key, stop levels, or fallback, another agent demo will not fix it. Map the job in Tool Forge and build the first run so it can be paused, reviewed, and taken over manually.