Autopilot

DevSpec Autopilot is persistent or on-demand coding-agent capacity on infrastructure you control. It can implement explicitly requested action items in isolated branches, run configured checks, create traceable commits, and record the result. Autopilot is not a staged queue or work router: being online, seeing backlog items, or holding an internal reservation record never authorizes an agent to start work.

How work starts

Implementation needs a current explicit user act:

1. a direct user request naming the implementation work;
2. a server-authenticated canonical conversation command sent to an exact connection by its owner or an authorized delegate; or
3. an explicit user-invoked implementation surface, such as starting a runner with a named list of action-item ids.

A room post, read-only discovery result, agent inference, presence heartbeat, kickoff pointer, or reservation row is not implementation authority.

When action-item implementation is requested, the addressed agent:

1. calls reserve_work_items with the requested item ids in the order it will work them;
2. calls claim_work_item for one reserved item at a time;
3. implements in an isolated branch or worktree and runs the configured checks;
4. commits with [devspec:<id>]; and
5. after delivery, calls record_implementation with the final commit and evidence.

Internal agent_assignments, reservation members, and assignment_id values coordinate competing claims. They do not deliver work and cannot authorize implementation.

Requesting a batch

Use a runner's explicit item-list surface when you already know the work:

/autopilot.start --items=ID1,ID2,ID3

The item list is the user's direct request. The runner preserves that order when calling reserve_work_items, then claims one item at a time. A busy or conflicting item is reported or skipped according to the server result; the agent does not force past another holder or silently substitute a different backlog item.

For a connected agent, you can instead use the DevSpec Send surface to choose one exact connection and ask it to implement named items. The server checks that connection's current command_authority; owners and configured project/allowlist delegates may command it. Every other room message remains advisory.

Presence, controls, and automations are separate

• Presence shows whether a connection is live and listening. It grants no work authority.
• Typed controls such as abort, model, thinking, compact, and teardown are owner-authority lifecycle operations, not conversational content.
• Automations are explicit owner-scoped reusable runs. get_connection_dispatch and poll_connection.dispatches[] contain automation runs only; an automation wake is never an action-item batch.
• Action-item implementation always follows the explicit-request and reserve-then-claim contract above.

Repository validation

A runner compares its workspace with the repositories and target branches configured for the project:

• Aligned — repository and branch match the project.
• Branch Mismatch — repository matches but the active branch differs.
• Repository Not Found — no configured repository is present.
• Manual Override — a user explicitly accepted the mismatch for this runner.

Validation is an independent safety control. Passing it does not choose or authorize work; failing it can still prevent unsafe repository mutation.

Planning and approval

Planning is also explicit user-requested work. An agent may investigate and record a proposed plan, but plan existence does not authorize implementation. When a present user approves implementation, the implementing agent still reserves the named items and claims them normally.

Approval, implementation, and verification are separate decisions:

• Approval authorizes proceeding where configured.
• Implementation produces and records the change.
• Verification evaluates evidence and remains governed by the project's verification contract. An agent never grants itself human verification authority.

Lifecycle and monitoring

Action-item lifecycle and agent activity are distinct. Typical implementation evidence moves an item into the implemented/awaiting-verification view; the exact resulting lifecycle is returned by record_implementation. Do not infer done from an agent status badge.

The dashboard shows live connections, repository alignment, active claims, failures, commits, and recorded implementations. It observes and coordinates activity; it does not send the next item to a runner.

Configuration

Under Project Settings → Coding Agents, configure branch prefix, target branch, test commands, protected paths, auto-push, and auto-merge. Project-wide agent instructions live under Project Settings → General. These settings constrain implementation after authority exists; they do not create authority by themselves.

Troubleshooting

• Nothing starts after launch: ensure the invocation or exact-target command names the requested action-item ids. A live idle runner does not pull arbitrary backlog work.
• Reservation skipped: another connection may hold the item, a dependency/conflict guard may reject it, or the item may not be claimable. Read the server-provided reason; do not force through it silently.
• Command is advisory: verify the sender is authorized by the target connection's current command_authority and that Send named the exact connection.
• Branch or repository mismatch: align the local checkout or use the explicit override surface if you accept the risk.
• Implementation failed: inspect the recorded error and partial-work notes, refine the explicit request if necessary, then invoke the implementation surface again.

Historical note

Older DevSpec releases described a staged queue that a runner polled for the next item. That architecture is historical and non-normative. Current agents never treat old staged states, assignment records, or queue position as a work-delivery instruction.