SWE-AF: a multi-agent build runtime that runs as an AgentField capability

The gap SWE-AF aims at: one goal, several repositories, one pull request

Most coding agents assume the unit of work is a file or a function. SWE-AF assumes the unit of work is a goal statement plus one or more repositories, and it tries to carry that goal through planning, implementation, testing and review without a human relaying messages between stages. The README frames it as an autonomous engineering team runtime, with product managers, architects, coders, reviewers and testers modelled as separate agents. The audience is teams already invested in agent infrastructure: the entry point is an AgentField capability named swe-planner.build, so you need an AgentField deployment before any of this runs. If you are looking for a CLI that edits your local checkout, this is not that shape of tool. The multi-repository mode is the more unusual part. A goal like adding JWT auth across an API and a shared library is expressed as config.repos, an array where each entry carries a repo_url and a role. That role field is not cosmetic: primary failures block the build, dependency failures are captured but do not block. That single rule encodes a real opinion about how cross-repo work should degrade, and it is the clearest design decision in the README.

The control stack: hardness-aware execution and DAG-level replanning

The README describes the architecture as planning, execution and governance agents running as a coordinated control stack, and it states plainly that the strategy lives in the architecture rather than in the prompts. The one mechanism described in any detail is hardness-aware execution: easy issues pass through quickly, while hard issues trigger deeper adaptation and DAG-level replanning instead of blind retries. That distinction matters because retry loops and replanning have different cost profiles. A retry repeats the same step with the same inputs and hopes for a different sample. Replanning rewrites the dependency graph, which means downstream work can be reordered or dropped. The README does not publish the threshold that separates easy from hard, nor the signals that trigger a replan, so the behaviour is asserted rather than specified. Model selection is per role. The config object accepts a models map with keys like default, coder, qa and architect, and the README states that any role key can be pointed at any model the runtime supports, across Claude, OpenRouter, OpenAI and Google. That is the most concrete lever a cost-conscious team gets: a cheap model on qa and an expensive one on coder is a supported configuration, not a workaround.

Invoking a build: the af CLI call and the raw HTTP equivalent

The README gives two entry points for the same capability. The CLI form requires af version 0.1.87 or later and streams progress before printing the result: af call swe-planner.build --in followed by a JSON object containing goal, repo_url and a config block. The HTTP form posts to http://localhost:8080/api/v1/execute/async/swe-planner.build with the same payload nested under an input key. Note the asymmetry: the CLI takes goal, repo_url and config at the top level, while the HTTP body wraps them in input. Copying one payload into the other endpoint without adjusting the nesting will not work. The config keys shown in the README are runtime, models, enable_learning and repos. runtime is set to claude_code in every example, models is the per-role map, and enable_learning is a boolean that the README sets to true without explaining what is learned or where it is stored. For a single repository you pass repo_url for a remote or repo_path for a local checkout, and the README states that SWE-AF handles everything else. The async endpoint name suggests the call returns before the build finishes, which is why the CLI advertises live progress streaming; the README does not document a polling or status endpoint, so how you observe a build started over raw HTTP is not covered in the material.

The benchmark table and why its methodology note changes the reading

The README features a benchmark from a Rust-based Python compiler example, described as built autonomously. The table reports steady-state execution 88.3x to 602.3x faster, a geometric mean of 253.8x, and peak throughput rising from roughly 52 ops/s to 31,807 ops/s, about 612x. Read the table alone and it looks like a claim about general system speed. The collapsible methodology note says otherwise, and credit to the README for including it. The comparison is between spawning a CPython subprocess at roughly 19ms per call and running a pre-warmed RustPython interpreter pool in-process. Those are different execution models, not two implementations of the same one. The note states this directly: the system was built to replace repeated subprocess invocations with a persistent pool for short-snippet execution. So the number measures the value of that architectural swap on that workload. It says nothing about how SWE-AF performs on a different repository, and the README presents no second benchmark. Treat the figures as evidence that the system can carry a substantial optimization through to completion, which is what the artifact trail supports, rather than as a performance characteristic of SWE-AF itself.

What the artifact trail does and does not establish

The README points to 175 tracked autonomous agents across planning, coding, review, merge and verification in the compiler example, with details in examples/llm-rust-python-compiler-sonnet/README.md, and links a single example pull request in the agentfield repository. That trail is the strongest maturity signal in the material, because it names the stages a build actually passed through. It is also a sample of one. Nothing in the README reports how often a build fails to reach a pull request, how many replans a typical hard issue triggers, or what the agent invocation count looks like for the multi-repository mode. The README does say SWE-AF scales from simple goals to hard multi-issue programs with hundreds to thousands of agent invocations, which is a useful order of magnitude for budgeting and also the clearest statement of where cost accumulates. A build that fans out across a fleet of role-specific agents will bill per invocation, and the per-role model map is the only cost control the documentation exposes. There is no mention of a spend cap, a budget parameter, or a dry-run mode anywhere in the README.

A different approach: a single coder loop you drive yourself

The README positions SWE-AF against frameworks that wrap a single coder loop, and that contrast is the honest one to evaluate. A single-loop agent, such as a coding CLI you run interactively, keeps you in the decision path: you read the plan, approve the diff, and decide when to stop. Its failure mode is your attention, and its cost is bounded by how long you sit with it. SWE-AF moves the coordination into the runtime, with separate planning, execution and governance agents and a dependency graph that can be rewritten mid-build. You trade supervision for throughput and you trade a predictable session for a variable number of agent invocations. The multi-repository role split has no counterpart in a single-loop tool: a dependency repository whose changes fail will not block the build, which a human driving one repository at a time would have to decide case by case. If your work is one repository and one reviewer, the single loop is cheaper and easier to reason about. SWE-AF earns its overhead when the goal spans repositories and the plan genuinely needs to be revised as the work proceeds.

Licence, maintenance and the public beta constraint

SWE-AF is Apache-2.0, a permissive licence that allows commercial use and modification, and the repository includes a LICENSE file. Apache-2.0 carries an explicit patent grant and requires that modifications be marked; if you fork the runtime, that obligation follows you. This is a description of the licence text, not legal advice, and anyone embedding SWE-AF in a product should read the terms with their own counsel. On maintenance, the material is thin in a way worth naming. The repository shows no retrieved releases, so there is no versioned artifact to pin, and the README labels the project a public beta. The one version number that appears anywhere is the af CLI requirement of 0.1.87 or later, which constrains the host tool, not SWE-AF itself. The primary language listed for the repository is Go, while the README's badges and examples are Python 3.12 and JSON, so the split between the runtime and the capability layer is not explained in the material. Upgrading means tracking the main branch of both SWE-AF and AgentField, and the README gives no compatibility matrix between them.

Editorial conclusion

Adopt SWE-AF if you already run an AgentField instance and want a single swe-planner.build call to drive plan, code, test and PR across one or more repositories, with per-role model selection. Do not adopt it if you need a stable interface, a published release history, or a runtime you can audit from a frozen version, because the repository shows no retrieved releases and the README labels the project a public beta. Before wiring it into CI, verify three things against your own checkout: that the af CLI you have is at least 0.1.87, that your runtime and model names resolve under claude_code or your chosen provider, and that the primary/dependency role split matches how your repositories actually fail together.

Official sources

1. Agent-Field/SWE-AF on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README