Autopilot

The background task queue runs work you queued. The autopilot is the next step: werbos acting on its own initiative. Drop a request in <inbox>/requests/ and it decides which skill to run, runs it, judges the result, corrects on a miss, and learns from the outcome — without being told how.

It’s opt-in and off by default (werbos serve --autopilot). An autonomous loop that runs skills unattended is exactly the thing that needs a leash, so the leash ships before the loop runs.

The fast loop — predict, act, observe, error, correct

This is predictive coding, the same way your eyes track a moving object: predict where it’ll be, then correct on the error.

1. PREDICT — a forward model reads the request and writes down, before acting, which skill it’ll use and what it EXPECTS the result to be. (Writing the prediction down first is what makes it a forward model and not a plain router.)
2. ACT — it dispatches that skill itself.
3. OBSERVE — captures the actual result.
4. ERROR — a judge compares expected vs actual. The gap is the prediction error.
5. CORRECT — on a miss, retry with the next-best skill.

Every iteration appends {request, prediction, action, outcome, error} to an experience log (~/werbos/experiences/, same 0700/0600 + schema-header discipline as the trace log). That log is the keystone: the real-time prediction error becomes the slow loop’s training data.

The slow loop — learn a routing policy, gated

On an interval, the autopilot distils the satisfied experiences into a routing policy — which skill actually worked for requests like this — and gates a fresh candidate against the incumbent:

• train a candidate on a train split of the experience log;
• score the candidate and the current champion on a held-out split (deterministic, genuinely unseen);
• promote the candidate only if it strictly beats the champion.

This is the champion/challenger gate the model trainer uses, applied to the autopilot’s own forward model. It’s the never ship a worse policy guarantee — the difference between a loop that improves and one that drifts. Promotions are versioned and append-only; you can roll a policy back. Once promoted, the policy plugs back into the fast loop (LearnedPredictor), falling back to the LLM whenever it has no confident signal. Two clocks, one loop: the error that corrects a turn now is the same error that retrains the router tonight.

The leash — why it’s safe to let it run

Fail-closed, defense in depth (the same posture as the werbos serve bind guard):

• Safe-skill allowlist — the autopilot only runs skills you’ve OK’d. The catalog is filtered before the model sees it and enforced again at act-time, so a prediction naming a destructive skill is refused and logged, never run. The default set is conservative and read-only; widen it with --autopilot-skills or WERBOS_AUTOPILOT_SKILLS.
• Dry-run (--autopilot-dry-run) — predict and judge, apply nothing, leave the request in place. Watch what it would do.
• Append-only revert — werbos autopilot revert <trace_id> (or --last) restores the request and logs the reversal; history is never rewritten.
• Trace everything — every tick emits predict / outcome / correct / refused / revert events under one trace_id, so glasshouse trace <id> shows exactly why it acted.

Watch it — and ask it about itself

Three surfaces, revert from any:

werbos autopilot watch            # live self-refreshing terminal screen
werbos autopilot list | status    # snapshots
werbos autopilot reflect          # what I know / am missing / would improve
werbos autopilot train            # run a slow-loop cycle by hand
werbos autopilot revert --last    # undo the most recent action

Plus a dashboard panel (the Autopilot route, backed by GET /api/autopilot + POST /api/autopilot/revert).

The most useful output is the reflection. werbos reads its own experience log and tells you, in plain terms, what it knows about itself, what it’s missing, and what it would like to improve. The richest signal there is the refused actions — the skills it reached for but wasn’t allowed to run. It literally names the capabilities it wishes it had.

See also

• The flow page — the autopilot loop diagram alongside the other eight dogfooding loops.
• Background tasks — the queued-work counterpart to the autopilot’s self-directed work.
• How to train — the model-training champion/ challenger gate the autopilot’s policy gate mirrors.