One-Line Summary: Background workers are agents the harness runs between user turns — auditing recent changes, optimizing code, looking for test gaps, refreshing memory — without requiring the user to ask, and they are one of the most important emerging patterns in 2026 harnesses.
Prerequisites: Sub-agents as primitives, hooks and lifecycle events, what is an AI harness
Status: Module 07 anchor concept — first draft. Authoring backlog: bespoke
ExplorerAHOBackgroundWorkerPattern(worker-trigger swimlane) per the plan file.
What Is a Background Worker?
A background worker is a full agent — with its own loop, tools, and termination condition — that runs in response to harness lifecycle events rather than user prompts. Ruflo ships with twelve: audit, optimize, testgaps, dependency-scan, cve-watch, memory-compact, and so on. Each is triggered by a hook (most often SessionStart, Stop, or a timer) and runs asynchronously while the main agent waits for the next user prompt.
The pattern is recognizable from web applications — background jobs, cron, queues — but the agent twist is that the worker is goal-directed rather than scripted. An audit worker is given the goal "find regressions in the last five commits" and uses the same tool surface as the main agent to investigate, escalate, and report.
How It Works
A worker is registered with a trigger (which lifecycle event fires it), a goal (what it is trying to accomplish), a budget (token, time, or step cap), and an output channel (stdout, scratchpad, conversation injection, dashboard). When the trigger fires, the harness spawns the worker as a sub-agent with the worker's scoped tools and runs it to completion in the background. Most workers report to a shared scratchpad the main agent can read; some write directly to a UI panel.
Why It Matters
The user-driven model — agent acts only when asked — leaves enormous capability on the table. A coding agent that audits last night's commits before you sit down has caught a class of regression you would otherwise have shipped. The pattern is also what makes harnesses feel proactive rather than reactive — a meaningful UX axis.
How Harnesses & Frameworks Implement This
| Harness / Framework | Background workers |
|---|---|
| Claude Code | Roll-your-own via SessionStart hooks |
| Claude Agent SDK | DIY |
| ruflo | First-class: 12 auto-triggered workers; ruflo-loop-workers plugin |
| LangGraph | DIY — schedule via external runner |
| AutoGen | DIY |
| CrewAI | DIY |
| OpenAI Agents SDK | DIY |
| Codex CLI | None |
| Cursor | Limited — background indexing of code, not agentic workers |
Connections to Other Concepts
audit-and-optimize-workers.md,testgap-and-coverage-workers.md— Specific worker types.autopilot-modes.md— The user-facing setting that gates how aggressively workers run.continuous-execution-loops.md— The execution-model side.event-driven-harness-architectures.md— The architectural pattern this depends on.hooks-and-lifecycle-events.md— How workers are triggered.
Further Reading
- ruvnet, ruflo-loop-workers documentation — The reference implementation.