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
Throughput workflow

Parallelize frontend and backend implementation

One task, two surfaces, two specialist sessions working at the same time in their own worktrees — then a controlled integration before anything reaches review.

Cloud is a future offering outside the initial self-hosted release. Registering interest creates no service or launch commitment.

What does this throughput workflow workflow cover?

One task, two surfaces, two specialist sessions working at the same time in their own worktrees — then a controlled integration before anything reaches review.

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

A feature needs an API change and the interface that consumes it. Done in sequence, the frontend waits a day for a contract that could have been agreed in ten minutes. Done in parallel by two agents on one checkout, they overwrite each other and the test run reports a state that never existed.

The current workflow

1Split the work in a planning call, agree the contract verbally
2Two branches drift; the API shape changes without the client knowing
3Integration happens in a rushed merge on the development branch
4Whoever reviews it reads two unrelated diffs and hopes

The BranchRunner workflow

  1. 01
    Contract first

    The planner writes the interface contract as a requirement both sessions must satisfy. It is agreed by a person before either starts.

  2. 02
    Two worktrees, one run

    Each specialist session gets its own worktree and container set. Neither can overwrite the other, and each runs its own checks.

  3. 03
    Dependency held explicitly

    The client step depends on the contract step. If the contract changes, the dependent step is reopened rather than silently invalidated.

  4. 04
    Controlled integration

    An oversight session merges both worktrees in a merge workspace and runs integration tests there — not on the development branch.

  5. 05
    One reviewable change

    Review sees one integrated diff against one requirements ledger, and one approval opens one pull request.

In the product

Run 24 on TASK-511: two implementers, one merge workspace, integration tests attached to the contract requirement.

Agent sessionsRun 24 running
  • PlannerContract agreed · 6 requirementsCompleted
    • Implementer · APIworktree a · 62.4k tokensCompleted
    • Implementer · webworktree b · 54.1k tokensRunning
    • Oversightmerge workspaceQueued
Worktree a
runs/br-511-api
Worktree b
runs/br-511-web
Merge
runs/br-511
Contract and dependencies
R1Endpoint returns paginated results with a cursorSatisfied
R2Response shape matches the agreed contractSatisfied
R3List view consumes the cursor, no client-side pagingIn progress
R4Integration test covers both surfaces togetherNot yet verified
Run context

Step 3 depends on step 2. The contract changed once at 11:14; the dependent step was reopened automatically and the web session re-read the requirement.

Needs attentionApprove integration in the merge workspace

Interface built from the product model. Repository, task and identities are examples.

Where a person stays in control

Contract approval

Parallel work only starts once the interface between the two surfaces is agreed by a person.

Contract change

Any change to the contract reopens the dependent step and notifies the owner instead of drifting quietly.

Integration approval

Merging the two worktrees is an approved step, with integration test results attached.

Single delivery decision

One approval opens one pull request, so nobody merges half a feature.

What to expect

·Two surfaces progress at once without a shared checkout
·Contract drift surfaces as a reopened step, not a broken build
·Integration problems are found in the merge workspace
·Review effort stays at one change per feature
Parallel work costs more per task: two sessions, two environments, more worker minutes. It is worth it when the surfaces are genuinely separable, and wasteful when they are not.

Deployment considerations

Capacity
Two worker slots per run, plus one for the merge workspace
Environment
Compose definition that can start both surfaces together
Checks
Per-surface checks, plus an integration test in the merge workspace
Concurrency
Set a per-repository limit so parallel runs cannot starve the pool
Edition
Cloud for one team; Enterprise for pools per team

Run two agents on one feature, safely

Separate worktrees and a controlled merge are built in. You do not have to invent the integration discipline yourself.

Register Cloud interestAll use cases
Cloud is a future offering outside the initial self-hosted release. Registering interest creates no service or launch commitment.