Skip to content
AnnouncementInitial release: self-hosted on Ubuntu 24.04 and 26.04 LTS. More platforms planned; Cloud and managed services are outside this release.First release: self-hosted on Ubuntu LTS.Release status
Register Cloud interest
Cloud interest
Governance workflow

Govern continuous backlog execution

Run a queue of specified work under policy, concurrency and budget limits. People review what asked for attention and what completed — not every step of every run.

Concurrency, policy scope and retention are agreed with you.

What does this governance workflow workflow cover?

Run a queue of specified work under policy, concurrency and budget limits. People review what asked for attention and what completed — not every step of every run.

What should an evaluator inspect?

Inspect the stated requirements, workspace boundary, validation evidence, approval points, and stated deployment scope rather than inferring results from an example workflow.

Is this customer proof?

No. Workflow pages describe an evaluation model and may use fictional product artifacts. They do not assert customer adoption, outcome, or availability evidence.

Can we run this workflow today?

A released self-managed artifact and tested quickstart are not published. Review the self-hosted requirements or register interest in future Cloud or Enterprise offerings.

What is the next step?

Use the ungated sample run and pilot scorecard to frame the evaluation, then choose a request path only if the operating model fits.

The problem

Once agents work reliably on single issues, the obvious next step is to point them at the backlog. That is also where it goes wrong: unbounded spend, twelve pull requests nobody asked for, and no way to tell which changes had human judgment applied and which did not.

The current workflow

1A script loops over issues and starts agents without limits
2Spend is discovered at the end of the month, per provider
3Review becomes a queue of unexplained pull requests
4The team turns it off rather than tighten it

The BranchRunner workflow

  1. 01
    Admit work deliberately

    A queue accepts tasks that meet an entry policy: specified requirements, an owner, a repository in scope. Anything else waits for a person.

  2. 02
    Bound the machine

    Concurrency per repository, spend per run and per period, and a daily ceiling on delivered pull requests.

  3. 03
    Escalate, do not stall

    A run that needs judgment raises an attention request with its evidence and holds. The queue keeps moving around it.

  4. 04
    Review completions, not steps

    A person reviews the day's completed runs with requirements and checks attached, and approves delivery in batch.

  5. 05
    Tune from evidence

    Outcome, duration and cost per task type inform which work stays in the queue and which returns to people.

In the product

An operations view for one working day: what the queue admitted, what needs a person, and what the limits allowed.

Needs attention3
521Requirement conflicts with the ledgerDecide
518Approval for a destructive commandApprove
509Soft budget threshold reachedRaise or stop
Concurrency · payments5 of 6 runs
Spend today$62.40 of $120.00
Deliveries today7 of 10 pull requests
Queue · today18 admitted
523Add pagination to the audit endpointRunning
522Upgrade the http clientReview
520Remove the deprecated webhook pathCompleted
517Fix timezone handling in exportsCompleted
514Backfill missing invoice numbersFailed
512Tighten rate limit on public searchQueued
Completed 7In review 4Failed 2Waiting on a person 3
Run context

Two tasks were rejected at admission: no owner, and requirements not specified.

Interface built from the product model. Repository, tasks and figures are examples.

Where a person stays in control

Admission policy

Which repositories and task types the queue may take, and what a task must contain to be admitted.

Limits with teeth

Concurrency, spend and delivery ceilings stop work rather than warning about it after the fact.

Attention queue

One place that lists every run waiting on a decision, ordered by severity, with the evidence attached.

Delivery approval

Pull requests still open on a human decision, in batch, and always as drafts into your normal review.

What to expect

·A predictable daily volume rather than an unbounded one
·Review time concentrated on completions and escalations
·Cost per delivered change visible per repository and task type
·Some task types will prove unsuitable; the evidence shows which
This workflow depends on a specified backlog. Vague issues produce vague runs, and the admission policy is there to keep them out rather than to hide them.

Deployment considerations

Capacity
Sustained concurrency, so a worker pool rather than a single host
Policy
Organization-level rules inherited by every team and repository
Budgets
Per run, per repository and per period, with named owners
Identity
SSO and RBAC, so approvals are attributable to real people
Retention
Long-term evidence retention for the runs you delivered
Edition
Enterprise, or Cloud for a single team's backlog

Point agents at the backlog, with limits

We will walk through admission policy, budgets and the review rhythm for your organization before you turn anything on.

Register Enterprise interestAll use cases