Working with AI

Agentic Drive

Introduction

A prompt gives you one answer and waits for you to decide what's next. An agentic loop gives the AI a goal and lets it work toward it autonomously — planning, executing, verifying, and iterating until the job is done. For software, this is especially powerful because code is easy to verify: your test suite either passes or it fails.

xpo drive gives you the power of agentic loops on top of your backlog. You plan your work together with your agents — write specs, set priorities, link dependencies — and xpo drive manages the agent loop to implement it.

What you get

Manual prompting makes you the orchestrator — you hold the plan, feed steps to the agent, review, course-correct, and repeat. xpo drive takes that coordination job off you entirely. You approve a spec, and stories go from PLANNED to DONE with a merge and a walkthrough while you work on something else.

You don't even need to write the spec from scratch. Have your agent draft it, review and refine it yourself — humans are better at editing than starting from blank pages — and let drive handle the rest. The quality of the output doesn't depend on your vigilance: xpo drive has built-in structural safeguards (separate reviewer, test gates, retry with feedback) to keep work consistent whether you're watching or not.

The result is throughput that doesn't scale with your attention. One person with xpo drive --loop can clear a backlog that would normally take a team-week. The bottleneck shifts from "how many agents can I supervise" to "how well are the specs written."

Command reference

xpo drive                         # pick the next PLANNED issue
xpo drive --id <id>               # drive a specific issue
xpo drive --dry-run               # preview which issue would be picked
xpo drive --no-merge              # leave branch for review
xpo drive --resume                # pick up an in-progress issue
xpo drive --filter "backend"      # only issues with this label
xpo drive --supervisor claude --coder claude

What happens when you run it

A drive run moves through five phases:

Preparation. A supervisor agent reads the issue spec and evaluates whether it's implementation-ready — clear acceptance criteria, enough detail to know what "done" looks like. If the spec is vague, the supervisor revises it and saves the revision back to the issue. Then it scans the repo and builds a context plan: which files matter, which patterns to follow, and which test command to use.

Implementation. A separate coder agent receives the spec, the context plan, and the relevant file list. It works on a dedicated feature branch, implementing the change and committing when it believes the work is complete.

Testing. Your test suite runs. Pass or fail is binary — there is no self-assessed confidence score. The test output is captured for the next phase.

Review. The supervisor agent — not the coder — evaluates the diff against the original spec, alongside the test results. If the review fails, specific feedback is sent back to the coder for another attempt. This retry loop continues up to a configurable limit (default: 3 attempts). If the limit is reached, the issue is marked BLOCKED with the last feedback attached as a comment.

Completion. Once tests pass and the supervisor approves, a structured walkthrough is generated — covering rationale, a file-by-file breakdown of changes, non-obvious decisions, how to verify, and what to look out for. This walkthrough is persisted as a comment on the issue. The branch is squash-merged (or left for human review with --no-merge), and the issue is marked DONE. A final summary reports wall time, token usage, and cost.

Visible work, not black-box magic

The hardest part of autonomous agents is trusting the output. xpo drive addresses this in two ways.

Every successful run produces a full walkthrough — not a summary, but a structured explanation of what changed and why, written by the supervisor after reviewing the final diff. It covers rationale, file-by-file changes, non-obvious decisions, steps to verify, and areas to watch out for. The walkthrough is persisted as a comment on the issue, so it becomes part of the project history.

With --no-merge, the completed work stays on a feature branch. You get the walkthrough, you get the diff, and you review it exactly like a pull request from a teammate. Start there and as confidence grows, first drop --no-merge, then drop --id, then add --loop. Each step gives you more leverage without asking you to trust more than you've verified.

The trust gradient

You control how much autonomy the agent gets:

Posture	Command	What happens
Manual	`xpo drive --id <id>`	You pick the story. The agent executes it.
Automatic	`xpo drive`	The agent picks the highest-priority PLANNED story with no unresolved blockers.
Continuous	`xpo drive --loop`	The agent keeps picking and executing until the backlog is clear.

Add --no-merge to any of these to leave the branch for your review instead of merging automatically.

Common problems with loops — and how xpo solves them

The agent grades its own homework. Most loops ask the same model "is this done?" and almost always hear "yes." In xpo drive, the supervisor that reviews is a separate agent from the coder that implements — they can be different models. Your test suite provides the hard gate: pass or fail, no self-assessed scores.

No memory between runs. Each session starts from zero. In xpo drive, spec revisions, review feedback, and walkthroughs are saved as issue comments. Branches are named after issues. --resume picks up where a previous run stopped, with full context of what was tried.

No stop condition. A loop with no exit runs until it succeeds or drains your account. xpo drive has a configurable retry cap (default: 3 attempts) and a wall-clock timeout (default: 30 minutes). On failure, the issue is marked BLOCKED — not silently abandoned.

Cost opacity. Most loops don't tell you what they spent. Every xpo drive run reports token usage (input and output) and cost in USD.

No recovery. When something fails, the work is gone. If xpo drive fails mid-run, you get exact commands to resume or discard. The work stays on the branch.