Ultracode: a concurrent agent fleet as an operational mode

Audience. Anyone orchestrating or auditing a concurrent agent fleet on one trunk — by the end you’ll know what “ultracode mode” composes, how its concurrency factor is defined so it can’t be gamed, and why it must never be blended with fak’s inference 5-10x.

This is the framing and metric-definition doc. It defines what “ultracode mode” is, which shipped pieces it composes, and — the load-bearing part — the value metric by which an ultracode run may claim a dogfood multiple, defined so it cannot be gamed. It reports no run results: the orchestrator writes the results doc separately and cites this one for its definitions.

Since this framing first shipped, fak ultracode has become a first-class CLI front door over the canonical orchestration resolver, its bounded Codex launcher, and status reader. That product surface does not change the metric below or create a new kernel primitive. Its current runtime/proof boundary is audited in ULTRACODE-NATIVE-RUNTIME-AUDIT-2026-08-20.md.

1. Definition

Ultracode mode is an operational discipline: orchestrating N independent coding agents working concurrently on disjoint file lanes of one repository, integrated back onto a single live trunk. It is not a new subsystem — it is a mode that composes pieces fak already ships:

So “ultracode” names a mode of operation over these shipped pillars and now also the fak ultracode command that selects its canonical orchestration profile. It remains a subcommand of the one fak binary—not a second binary, ABI, or kernel primitive. The command currently proves plan shape and can launch guarded read-only Codex workers; the full lease/effect/witness/reconciliation runtime remains tracked in #5970/#5971. The contribution is still the assembly and discipline, exactly as the rest of fak’s multi-agent story is “no single lever is novel; the contribution is the assembly.”

2. Why disjoint lanes (the shared-trunk constraint)

fak runs a single live trunk (main) that every session commits to directly — no per-agent branch, no per-agent worktree, no VM. The full trade is argued in notes/SHARED-TRUNK-VS-PER-AGENT-ISOLATION-2026-06-25.md; the operational consequence for ultracode is sharp:

The mode therefore only fits work that decomposes into disjoint lanes. That is a design constraint, not a detail (see §5).

3. The value metric (the core of this doc)

A dogfood run wants to claim a multiple. State exactly what that multiple is, and define it so it cannot inflate itself.

3.1 The concurrency factor

Concurrency factor = the number of independent, reviewed, correct deliverables completed in one orchestration window, where the serial-equivalent baseline is those same N deliverables produced by N sequential agent runs.

In plain terms: if an orchestration window produces N disjoint-lane deliverables that an auditor could otherwise have obtained only by running N agents one after another, the window’s concurrency factor is N. The multiple is agent-orchestration throughput, not quality and not tokens — it answers “how many independent units of reviewable work did one window land at once,” nothing more.

3.2 The Amdahl caveat (the ceiling)

The factor is bounded above by N and is reached only in the limit. The serial part is the orchestration itself — decomposition into lanes, lane arbitration, and the integration

State the realized factor and its serial-overhead context; never report a bare N as if the fold were free.

3.3 What makes a deliverable “count”

A deliverable counts toward the factor only if it is both:

  1. Independently reviewable — a concrete artifact (a file, a code change, a proof) that an auditor can open and read on its own, without trusting the agent’s narration.
  2. Correct and complete, not a stub — it does what it claims. A placeholder, an unfinished stub, a doc that asserts a test exists when the diff added none (dos commit-audit’s subject-only failure), or a half-done lane does not count.

This is the anti-gaming clause: the factor measures reviewed output, so an orchestrator cannot pump N by spawning more agents that each emit a stub.

3.4 This is NOT the inference 5–10x — keep the axes apart

fak makes a separate family of 5–10x claims about inference — decode/throughput on real hardware (the H100 kernel roadmap and the session value stack), not agent orchestration. Those numbers live in BENCHMARK-AUTHORITY.md (the single source of truth) and docs/benchmarks/ (e.g. H100-KERNEL-5X-ROADMAP.md). They are a different axis — tokens per second / cost per token on a GPU — measured by an entirely different method.

The one separation law. The ultracode concurrency factor (independent reviewed deliverables per orchestration window) and fak’s inference 5–10x (decode throughput / session-value-stack savings) are different axes measured by different methods. They must never be multiplied together, added, or quoted as one “5–10x.” A results doc that blends them is making an unsupported claim.

This doc deliberately does not restate the inference numbers — it points to where they live so the two are cited, never conflated.

4. Honesty rules

The metric obeys the proof method’s one rule (docs/proofs/00-METHOD.md): a claim is real only when a deterministic, re-checkable witness corroborates it — never because an agent says so.

5. When NOT to use ultracode mode

The mode is wrong, or net-negative, when:

In those regimes a single agent on the trunk, or a smaller fleet, is the honest choice.

6. References