One-Line Summary: Audit workers continuously inspect recent agent activity (commits, edits, decisions) for regressions, anti-patterns, or risks; optimize workers proactively rewrite code, prompts, or configurations toward measured improvements — together they form the most-cited concrete example of the background-worker pattern.
Prerequisites: Background worker pattern, hooks and lifecycle events
What Are Audit and Optimize Workers?
An audit worker runs after work is done and checks for problems: did the last five commits introduce regressions? Are there new test gaps? Are dependency versions vulnerable? Did the agent leave dead code? It is a quality assurance pass running between user turns.
An optimize worker runs proactively to improve work that's "fine but improvable": refactoring stale code, tightening prompts that drifted, removing dead config, suggesting smaller models for routine subtasks. It is a continuous improvement pass.
The two have similar shape (background, goal-directed, runs without prompting) but different temperaments. Audit is conservative — it surfaces concerns. Optimize is opinionated — it proposes changes. A mature deployment runs both; they balance each other.
How They Work
Both follow the same template:
- Trigger: A
SessionStarthook (or timer) fires. - Goal seed: The worker is given a goal — "audit recent work" or "find optimization opportunities."
- Read-only exploration: The worker uses read-only tools (git log, Grep, Read) to understand recent state.
- Finding generation: The worker emits findings — issues for audit, suggestions for optimize.
- Output channel: Findings land in a scratchpad the main agent reads on next turn, in a UI panel, or in a notifier.
Crucially, audit and optimize workers should not make changes — they propose. Letting them act introduces feedback loops where the agent fights its own background workers. The main agent (or the user) decides which suggestions to implement.
Why It Matters
Audit and optimize are the workers that justify the background-worker pattern's existence to skeptical users. The user experience is "I sat down and the agent already noticed three things that would have bitten me." That perceived value is hard to replicate in user-driven mode — the user doesn't know to ask.
The challenge is signal-to-noise. A noisy audit worker that flags every commit is ignored. A worthwhile audit worker fires only when it has concrete, prioritizable concerns.
Key Technical Details
- Read-only by default: Audit and optimize workers should not edit files, run destructive commands, or modify state. Their power is in noticing.
- Findings need priority: Without priority, every finding is equal noise. Severity (critical / high / medium / low) and confidence (certain / likely / possible) help.
- Idempotence matters: A worker that re-reports the same finding every session is annoying. Track previously-reported findings.
- Cost discipline: Workers run continuously; their cost compounds. Use cheaper models, scope tightly, exit early when no findings.
- Time-of-day awareness: Audit on session start (catch overnight regressions). Optimize on session end (when the user is winding down).
- Diff-driven scope: Audit the diff since last audit, not the whole repo. Massive scope reductions.
- Dispatch to specialists: Workers can spawn sub-agents for deep dives ("found a suspect file → spawn a dedicated reviewer").
How Harnesses & Frameworks Implement This
| Harness / Framework | Audit / Optimize workers |
|---|---|
| Claude Code | DIY — SessionStart hooks |
| Claude Agent SDK | DIY |
| ruflo | First-class — audit, optimize, testgaps, others among 12 default workers |
| LangGraph | DIY — implement as scheduled flows |
| AutoGen / CrewAI | DIY |
| OpenAI Agents SDK | DIY |
| Codex CLI / Cursor | ✗ |
Connections to Other Concepts
background-worker-pattern.md— Parent concept.testgap-and-coverage-workers.md— A specialized audit worker.event-driven-harness-architectures.md— The infrastructure side.continuous-execution-loops.md— The execution-model side.
Further Reading
- ruvnet, ruflo-loop-workers documentation.