Overview

Autonomous Work drives a real engineering cycle against a connected ticket — investigate, plan, implement, and validate — without a human present for each step, using the same execution engine and Coding Runtime a normal chat session uses, orchestrated headlessly.

It is not a second, separate coding engine. A dedicated ConversationRuntime instance is fed the ticket as a synthetic request and drives the same tool-calling loop a human-typed request would.

Lifecycle

1. 1

   Investigate

   Real evidence is gathered — console output, network requests, repository history, prior engineering memory — before anything is proposed.

2. 2

   Plan

   A concrete implementation plan is drafted and tracked as a live TODO list.

3. 3

   Implement

   Edits are applied using the same file-editing mechanism described in Coding → Code Editing.

4. 4

   Validate

   Real tests and the validation pipeline run against the change.

5. 5

   Report

   A structured engineering report captures what was found and changed, persisted as real memory.

Product disclosure

This disclosure is part of the PawOS documentation for Overview. It is written to make the product behavior understandable before a user relies on it, pays for it, connects an account, approves a plan, or authorizes a machine-affecting action.

What users see

• Autonomous Work appears as an unattended ticket-oriented run with investigation, plan, implementation, validation, completion, and charging state.
• Users should see eligibility, connector status, credit balance, ticket context, execution evidence, and final completion/charging result.
• When a connector cannot write back to the tracker, the user should see a structured report or supported PR/MR comment path rather than a claimed ticket update.

What PawOS does

• PawOS investigates the ticket and repository, creates isolated work where supported, applies changes through the same coding mechanisms, validates the result, and records evidence.
• Autonomous Work Credits are separate from Paw Compute and fund ticket completions only when completion criteria are satisfied.
• Billing logic is intended to be success-gated and protected against duplicate completion charges.

Permissions and boundaries

• Autonomous Work does not grant permission to install software, repair PATH, change system settings, or bypass user/organization confirmation gates.
• Connector capabilities differ by provider. Reading a ticket, commenting on a PR, creating a PR, and changing ticket status are separate capabilities.
• A run that is blocked, failed, or not verified should not be described as completed.

Evidence and records

• Completion should be supported by repository state, validation output, changed files, connector evidence where available, and billing/completion records.
• If independent connector verification is absent for a specific close/merge state, that limitation must remain disclosed.

Limitations and user responsibility

• Jira and Linear write-back from Autonomous Work is not implemented in the current docs.
• Automatic new PR/MR creation is not documented as implemented; supported connector actions should be described provider by provider.
• Eligible account, connector, repository, and credit conditions are required before an actual run can be validated.