Skip to main content

Background Agents: Durable Agent Tasks

Background Agents run OmniCoreAgent work outside the foreground request path. They are durable tracked tasks with schedules, retries, cancellation, leases, workspace output, and inspectable lifecycle events. Use the default in-memory store for local development, or sql, redis, or mongodb when runs must survive restarts.

Key Concepts

  • BackgroundAgentManager: Registers agents, tasks, runs, and lifecycle operations.
  • Task store: Operational state for agents, tasks, schedule state, runs, attempts, leases, retries, and cancellation flags. It defaults to in-memory and is separate from conversation memory.
  • Run: One concrete execution of a task. Runs have stable IDs, statuses, attempts, workspace paths, and event history.
  • Worker lifecycle: A worker claims queued runs with leases, heartbeats while work is active, and recovers expired leases.
  • Workspace output: Every background run gets a workspace namespace for lifecycle files and agent output.
You can run the background manager without storage configuration. Use BackgroundAgentManager() for the default zero-config in-memory task store. Use task_store="sql", task_store="redis", or task_store="mongodb" when task state must survive process restarts. The task store is not conversation memory; it is the control plane for background work. Redis and MongoDB task stores use optional backend drivers:

Quick Start

Durable Task Stores

The default task store is in-memory. It needs no database and is right for local development, tests, and single-process experiments:
Use a durable task store when background runs must survive process restarts:
Redis durable deployments need persistence enabled and a no-eviction policy for task-store keys. MongoDB task-store writes use majority write concern. Choose one durable backend per deployment. Use SQL/SQLite for local durability or simple single-node services. Use Redis when your deployment already operates Redis with persistence and no eviction for task-store keys. Use MongoDB when MongoDB is your durable operational store. Durable stores preserve queued runs across manager restarts. You can queue a manual run, stop the process, construct a new manager with the same task store, and complete the queued run from that new manager. The in-memory store does not provide that guarantee. OmniServe uses the same task-store settings through environment variables. Pick one backend:

Scheduled Runs

Manual tasks run only when you call run_now. Scheduled tasks are dispatched by the manager worker after start() is called:
start() creates the manager worker and returns immediately. Keep the process alive while scheduled work should continue, and use shutdown() when the process exits so worker loops and active background resources close cleanly:
The runnable scheduled example uses the same worker path without requiring an LLM API key:
It creates a due once task, starts the background worker, waits for the run to complete, then prints task status, manager status, lifecycle events, and the workspace files created for the run. By default it writes the demo workspace under your system temp directory. Set OMNICOREAGENT_COOKBOOK_WORKSPACE_DIR to choose a different location:

Real Application Background Task

The real application example runs the support operations app shape through the background manager. It uses the same support domain tools as cookbook/real_applications/support_operations_agent.py, registers a manual task, waits for the run to finish, then prints the run id, status, attempts, lifecycle events, and workspace files. It is deterministic and does not require LLM_API_KEY, so it is safe to run in CI or locally when you only want to inspect the background execution boundary:
By default, the workspace root is under your system temp directory at omnicoreagent_real_app_background_workspace. The script prints both workspace_root and the run-local workspace path. Pass workspace_dir when calling run_real_application_background_example(...) from Python if you want a specific local root. The run workspace contains:
  • output.md with the durable support note
  • tickets/tck-1042.md with the ticket-specific record
  • run.json with the latest run snapshot
  • events.jsonl with ordered lifecycle events

Runtime Controls

get_run_events(run_id) returns ordered lifecycle events for that run. These events use run-local names such as background_task_scheduled, background_run_queued, background_run_claimed, background_run_started, background_run_heartbeat, background_run_retrying, background_run_recovered, background_run_completed, background_run_failed, background_run_timeout, background_run_cancelled, and background_run_skipped. When workspace event mirroring is enabled, lifecycle events are also written to the run workspace events.jsonl file for durable replay and debugging.

OmniServe Endpoints

OmniServe exposes the same background run lifecycle over HTTP:
The background API includes manager status, task creation, task status, task listing, pause, resume, delete, manual run, cancellation, run status, attempt history, event replay, and workspace inspection.

Task Configuration

State is restart-persistent when the task store is SQL, Redis, or MongoDB.