Operating models / Autonomous Fleets

Operating Autonomous Fleets: A Product Operator's Runbook

A product operator's reference for authority, costs, context, and recovery in autonomous agent systems.

Explore the seriesUse the templates

From business outcome to operating model

Agent systems change how work is assigned, approved, paid for, and accepted. Product architecture connects those decisions to the customer or business outcome the work is meant to produce.

Start with that outcome and its acceptance criteria. Then define the owner, permitted actions, budget, and recovery policy. These choices determine how an organization can delegate work while retaining accountability.

This runbook is part of Architecting Intelligent Businesses, my work on the relationship between products, technical systems, and operating models.

The operating manifesto

An autonomous fleet is a group of software agents that can plan and carry out work across tools. Operating that fleet requires decisions about who may act, which changes need approval, how much work may cost, and what happens when execution stops.

This runbook proposes a product operator’s discipline: assign an accountable owner, define the permitted work, and require evidence before accepting the result. A role name describes a responsibility. The operating rules must also specify the tools, resources, and decisions available to that role.

The reference model follows four principles:

1. Define authority before assigning work. Name the owner and record what the agent may read, propose, and change.
2. Guard the write boundary. Check permission at the point where an action changes a file, system, or external record.
3. Account for the whole task. Include planning, context preparation, execution, review, and recovery in its budget.
4. Recover with evidence. Inspect the recorded state before resuming a stopped task, and preserve its identity and spending history.

Readiness check Before execution, name the accountable owner, define the permitted change, reserve its budget, and record the evidence needed to accept the result.

The files below are editable starting points. Their policies need an operator’s review and implementation in the system that executes the work. They do not grant execution permission.

Series overview

Four essays follow a task from role assignment through approval, budgeting, and recovery. Each entry opens an article page on this site. Unfinished entries are labeled Draft outline and show proposed editorial dates.

A bounded recovery policy

This work packet fragment sets the automatic recovery limit to zero. An operator must define the permitted actions and checkpoint before enabling recovery. The work packet schema describes the full document.

{
  "recovery": {
    "max_attempts": 0,
    "permitted_actions": [],
    "checkpoint_ref": null
  }
}

Escalation triggers Stop when approval is missing, the remaining budget cannot cover the next action, or the previous write has an unknown outcome. Record the evidence and the decision needed from the owner.

Reference templates and schemas

Read, copy, or download the reference files below, or fork the autonomous-fleets-artifacts repository to adapt them for your system.

Artifact	Purpose
Operating manual specification	Define ownership, authority, acceptance evidence, and recovery policy.
Role profiles	Assign responsibilities and proposed permissions to named roles.
Request-to-execution flow	Follow a request through approval, execution, review, and recovery.
Work packet schema	Describe the inputs and constraints carried with a task.

Start with the operating manual, adapt the role profiles, and use the flow to identify the checks your execution system must enforce. Validate a proposed work packet against the schema, then check its permissions and budget separately.

The reference templates and schemas are available under the MIT License.