What is Autobuild?
Published May 8, 2026 · Last updated September 24, 2026 · 4 min read
Autobuild is Obvious's system for running software development work with AI agents. You give it a spec, a document describing what to build, and it decomposes the work, assigns tasks to agents, opens pull requests, and tracks everything through to merge. It organizes work from initiatives down to single executables, so you can decide whether it fits your workflow.
What Autobuild does
When you point Autobuild at a spec, it creates an initiative, a container for the work described in that spec. From there it breaks the initiative into features (logical chunks of work) and executables (the individual tasks an agent will complete, one at a time).
Most executables produce a pull request. The agent reads the task, writes the code, opens a PR, and hands it back to you for review. Depending on the task, some executables produce other outputs, such as documents, configuration changes, or research. You stay in the loop on every decision point; Autobuild handles the work in between.
If something goes wrong mid-task, you can ask an agent to babysit a stalled PR, dispatching it back to the agent for another pass without starting over.
How work is organized
Autobuild uses a three-level hierarchy:
Initiative
├── Feature
│ └── Executable
└── Executable (direct child)
Initiative: the top-level goal. Corresponds to a feature, a sprint's worth of work, or any bounded deliverable you'd write a spec for.
Feature: a logical sub-group within an initiative. Not every initiative needs features; simple work can attach executables directly to the initiative.
Executable: the atomic unit. One task, one agent, one PR. An executable has a status that tells you exactly where it is:
| Status | What it means |
|---|---|
| planned | Queued, not yet started |
| queued | Handed to an agent, waiting to start |
| in progress | Agent is actively working |
| in review | PR is open and waiting for your review |
| paused | Work paused, will resume when unpaused |
| blocked | Waiting on a dependency |
| failed | Something went wrong and needs attention |
| completed | Work done |
| cancelled | Closed without completing |
What you see in the dashboard
Autobuild has its own section in the sidebar, labeled Autobuild.
The Autobuild home opens on a page that asks "What do you want to build?". Describe the work in the composer, and Autobuild starts a build from your description. Work you ask for shows up as a build under Your builds on the same page. Select View all to open all builds, where you can search and filter by status and decision.
Bug reports live in Atlas. Improvement requests live on the Improvements page. Neither appears on the Autobuild home.
If your workspace hasn't set up Autobuild yet, the home shows setup instead. Workspace admins can start setup from there.
For a walkthrough of your first build, see Your First Initiative.
How GitHub connects
Autobuild needs a GitHub App installed on your organization to open and track PRs. Setup walks you through connecting GitHub. After setup, you can manage the connection from Autobuild settings: select Settings at the top right of the Autobuild home, then open the Repos & Sandboxes tab. Once connected, you'll see your repositories listed and can import them into Autobuild.
For each imported repository, Autobuild can provision a repo sandbox, a pre-built checkout of the repo that agents use to run code safely. Sandboxes have their own status:
| Status | What it means |
|---|---|
| Available | Ready to provision a sandbox |
| Pending | Sandbox is being set up |
| Building… | Building the snapshot image |
| Ready | Sandbox is ready for agents to use |
| Failed | Sandbox build failed |
Before you set it up
To use Autobuild you need:
-
A GitHub organization where you can install a GitHub App
-
At least one Obvious project with a spec document
-
Workspace admin access to configure the GitHub connection