Agent pipelines made fast.

An example pipeline

  1. Opus 5.5 implementer 500k tokens
    • TDD reviewer 200k tokens
    • UIX reviewer 200k tokens
    • Performance reviewer 200k tokens
  3. Sol-6 verifier 400k tokens
An example pipeline: one implementer, three reviewers in parallel, one verifier from another vendor. Each Worker spends from its own token budget, 1.5M tokens in all.

Concepts

Workers

A Worker has one job: implement, review or verify. Most are agents, each with its own model and prompt; some are plain commands. Every one runs in its own sandbox and sees only the inputs it declares.

Pipelines

A pipeline wires Workers together: who goes first, who runs in parallel, who checks whom. You can read the whole plan before it spends a token.

Budgets

Every Worker gets a token budget, reserved before it starts. Limits nest and the tightest one wins: once it is reached, nothing more is dispatched.

Shared between engineers

Workers and pipelines are files under .af/, committed with your code and pinned by digest. The whole team runs the same pipeline, and a change to it is a diff you review like any other.

The code review problem, solved.

  1. Set up a multi-agent review pipeline that is the best for your task.

    af onboard drafts the first one: two model reviewers from two vendors, your project's check command as the Gate that must pass before they run, and token budgets. Then make it yours: add a TDD reviewer, swap a model, rewrite a prompt.

  2. The pipeline runs in a controlled loop and finishes with the perfect PR.

    The Gate runs first, then every reviewer in its own sandbox, and what they find lands in one ledger. You or your coding agent fix it. A default review is one Round; a deep review rechecks the fix until a Round comes back clean or its caps on Rounds and tokens end it. The change that comes through is the PR you open: af never opens it for you.

  3. Commit the pipeline definition and make it a part of your SDLC.

    The definition is a handful of files in your repository. Review them like code and merge them. From then on everyone on the team runs the same review, against the same pinned policy.

$ af onboard
af onboard: preview
…
pipeline    .af/pipelines/review.toml
lock        pinned by af 0.11.0 (digests: aarch64-apple-darwin, …)
topology
  …
  node correctness [reviewer]
  node architecture [reviewer]
  …
reviewers
  correctness: correctness / claude (claude-opus-5-5 (high effort))
  architecture: architecture / codex (gpt-6-sol (high effort))
gates
  check: make check [detected Makefile target]
budget      300000 tokens/Attempt; 1000000 tokens/Round
convergence 1 clean Round; 2 Round maximum
files
  …
  .af/pipelines/review.toml
  …
next
  …
  2. Review and commit the generated `.af/` diff on the trusted base branch.
  …
Real output of af onboard in a fresh repository, af 0.11.0, with lines left out. A preview writes nothing and spends no tokens.

Stop playing ping-pong with colleagues over code reviews.

Comment, fix, re-request, wait, repeat. Have those rounds with your pipeline first, before anyone is asked to look. Your colleague reads a change whose Findings are already answered.

Start building agent pipelines with afactory.

$ curl -fsSL https://github.com/PakhomovAlexander/afactory/releases/latest/download/install.sh | sh
Read the quickstart View the source

Open source · Apache-2.0 · macOS and Linux · public alpha