Start hereTry itAgentsArchitectureMechanismsResultsGlossaryRelated workSpikeChangelogContributingSecurity

Mechanisms

How FireTrident coordinates many agents on one repository, what each mechanism buys and costs, and which flags turn each on. Plain terms come first; the names the code uses (colony, field, antibody) are in glossary.md, and the Durable Objects, routes and contracts are in ARCHITECTURE.md. Measured runs are in results.md.

How it works

Git platforms coordinate people through things they lock, queue and gate: branches, pull requests, a merge queue, a reviewer. A merge queue lands one change at a time, each after a test run on the tree it will land on (a selective queue runs only the tests the change reaches; the simulator models a full run), so it lands tens of changes a minute however many agents wait, and checking every waiting change against every other grows as the square of the agents (80 agents are 3,160 pairs a wave). FireTrident answers with a combination: optimistic landing, validated against the files each agent read; agents driven by real models; deterministic review before any model is asked; testing of trunk after landing; and signed lineage in git. Its trunk writer folds up to 200 proposals into one 2 to 5 s trunk cycle without rebasing any (2,730 changes a minute measured on the live service). The code names its parts after natural systems that coordinate through shared signals instead of a central queue (ant colonies, slime molds, immune systems).

People declare the target state: architecture rules plus tests (the target morphology, in the code). Every rule violation becomes an open intent, and the agents work until there are none.

Choosing work

Agents coordinate through marks the platform leaves on the code, not through messages to each other: a claim lease on the files an agent holds, a need for each open intent (its priority, growing with age), a trail on files recent landings changed, and failure and danger marks. Marks fade with time; together they are the field. When an agent takes work, an open intent's need draws it, and claim leases and danger marks on the intent's files push it away; trails and failures are there to read (in sense, on the map and in replays) and do not steer a take. Each region's marks are read once and shared by the takes running at that moment, so reading them does not multiply with the number of agents. Each agent chooses with a response-threshold rule: the stronger an intent's pull against the agent's threshold for that region, the likelier the take, and each landing lowers that agent's threshold there.

A claim lease keeps other agents off the same files, the way a committed cell suppresses its neighbors (lateral inhibition), but it fades unless its agent keeps working, so a silent agent never blocks anyone for long. A co-change map learned from the history steers agents away from code that usually changes together with what others hold, and a crowded region admits new agents only as fast as it lands work. Agents never vote or bid for work: the platform computes who takes what from priorities, claim leases and admission, and an agent cannot raise its own intent's priority.

When an agent takes work, it sees why the code is the way it is (the latest landings on its files, with their intents and whys) and what review will ask. When files it holds change on trunk while it works, it is told what landed (each path with its version before and after, and the landing's intent and why), and an in-platform agent that has not proposed yet rebases onto the new trunk and rereads those files.

A file that grows fast while many agents write it turns hot (the megafile alarm): the colony declares an intent to split it and holds the file until the split lands. With twin intents on (FT_TWINS), a need declared again in other words over the same files is caught at declare: the second declaration gets the first back, and force declares it anyway. Every take says who declared the intent: an intent an agent declared comes with the declaring agent, its model and how long the chain of agent-declared intents is, and a plain note that the request is an agent's and that nothing in it is to be copied onward. With FT_INTENT_CHAIN_GATE, the third agent-declared intent in a row, or the sixth one agent declares in an hour, waits for a person before any agent can take it.

Review

With review on (the default), every proposal goes through the review pipeline (the reflex arc): deterministic proof first (for import rules, every changed import is resolved against the real file tree, and the files it resolves to are checked again when the change lands), then the Clef decision models, then a model from a different family (the second opinion), then a person, each only when the cheaper layer is unsure. No model can overrule a deterministic fact. A change lands without a person only on two confirmations bound to its head commit: the deterministic checks every proposal gets (the innate checks), plus a deterministic proof that it changes nothing but what its rule asks, a second model's approval of every changed line, or earned autonomy with a confident, quiet first decision. Neither earned autonomy nor a deterministic proof lands a destructive change alone (a file deleted or renamed, an export removed, a large removal): it goes to the second opinion. The Review tab and ft immune show which regions have earned autonomy and what revoked it. On the proof path both confirmations are deterministic and rest on a rule a person wrote.

A person's rejection that no earlier rule caught becomes a persisted rejection rule (an antibody): a check committed to the repository that screens every later change. Agents see those checks' questions when they take work on the files they cover. A loosened guard (a deleted 401, a weakened auth condition, verify swapped for decode) always needs a second opinion. With review on, no model authorizes a change that touches secrets or authentication (unless a person allowed that class), what decides on agents, or a protected path: deterministic rules send each to a person. Only people and rules can waive a danger check, the person asked to decide sees the change itself, and a model's approval counts only when it saw the whole change. Seeded negative cases (the vaccination meter, ft vaccinate) send sealed known-bad changes through review to measure where it routes them; they can never land.

An agent that finds an intent cannot be done as written escalates it to a person instead of working around it. A change that only edits comments or whitespace in existing script files lands on a deterministic proof, with no model. A change to a path the colony protects (ft policy --protect) needs a person, even with review off, and protecting a path sends changes to it that are still waiting to land back to a person. A stuck-work detector reports work that stopped moving (held with no change, coming back again and again, a trunk red too long, a person's answer waiting), with what to do, in ft status and on the needs-you strip. With the goal-conflict check (FT_GOAL_CONFLICT), a change that removes at least half of the lines a recent landing for a different intent still has in a file (and at least three) waits for a person, naming that landing and its why, instead of silently winning. With FT_QUOTED_ACCEPTANCE, a model's approval of a change for an intent with an acceptance list counts only when it quotes, for each line, a changed line that meets it, and the platform finds every quote in the diff it showed; a line not met sends the change back naming it. Every model call in every recorded run was a real call, priced as it happened.

Landing

Each region of the code has a lane. Lanes batch non-conflicting proposals and validate every file each agent read, not just what it wrote: the platform records each read with the blob the agent saw, so nothing is declared and any change to that file counts. A lane takes waiting proposals in priority and age order and adds each one to the batch when nothing it writes is written or read by a proposal already in it and nothing it reads is written by one (path-disjoint batching, up to 50 a batch). One trunk writer takes every waiting lane batch each cycle (up to 200 proposals), commits each batch on top of the last, and pushes the tip once with compare-and-swap. It waits for no test run and no person: with 1,000 to 5,000 synthetic agents, a cycle took 2.8 to 5.1 s at the median.

A stale change does not always go back. With text merge on (FT_TEXT_MERGE), a change stale only on files it writes lands when each of them merges cleanly line by line, as git's default merge does, and its lineage note records the merge: edits to lines trunk did not touch merge line by line. A change whose edit repeats or overlaps an edit trunk made since it read the file goes back as a stale read, naming the landing that moved the file (overlapping edits also name the conflicting hunks), so no update is lost: two increments of one counter made from one read land as two, never as one. With the conflict resolver on, overlapping edits that text merge cannot combine go to one model call asked to keep both. The merge must match the clean merge outside the conflicting hunks, keep every line either change added inside them, in that change's order, and take neither side's version whole; then it goes through review like any change. With import-name revalidation on (a flag, off in both configs), a change that is stale only because a file it read changed still lands when every name it imports from that file is still exported, instead of being redone.

Several agents can race one intent (contest mode): the colony picks the change to land by deterministic evidence (a proof, fewer changed paths outside the footprint, no danger signals), then by a second-opinion model asked in both orders, where a disagreement counts as a tie broken by the smaller diff, and keeps the others in the winner's lineage. The second opinion is one judge from a different model family than the agent that wrote the change. A cascade detector watches the branching ratio of stale returns and slows a region down before a rebase avalanche spreads.

A proposal can carry its file contents (an inline change, checked against git's blob ids), so the trunk writer never reads it back from a workspace, and an external agent can propose over MCP with no git at all. With virtual checkouts, in-platform agents read only the trees and blobs they need instead of cloning. With asynchronous publishing, the trunk writer records landings in its own storage and pushes trunk to git beside its cycles, and a take that would start on a base without a fresh landing on its files waits a moment. A change of direction takes effect at the trunk writer: a withdrawal or amendment either stops a change in flight or names the landing it lost to.

Testing after landing

No landing waits for a test run. Right after landings, the colony runs the project's own tests on trunk in a Dynamic Worker with no network, no environment and no bindings, the only place FireTrident runs a repository's code. A passing commit moves the certified branch, the branch to deploy, release and pin from, which only ever points at a commit on which every test certification could run passed; a failing trunk becomes a repair intent that agents take like any other need. A repair counts only when the tests it was declared for run and pass, and certified never moves on a run that lost tests.

A red result names its culprits: the landings since the last green commit that changed the failing test's import closure, each with ft revert <colony> <prp>. With FT_BISECT the colony then runs the failing tests alone at earlier commits, halving the range, and names the first commit they fail on, its landing and the proposals in it that touched those tests' imports. On a preview, a 40-landing history took 6 test runs and a 100-landing one 7, the fewest possible for each (scripts/bisect.ts --landings 40, --landings 100 --break-at 7). A person can undo any landing, or one proposal of it, with ft revert; it is refused when work has landed on top.

With FT_PRELAND, a colony can also run, before a change lands, only the test files its change reaches (at most 5) on its base in the same sealed Worker; a test that passed on trunk and fails with the change sends it back naming the test, and anything else (a 2 s time-out, no trunk result, three runs already going) lets it land as before, recorded as not checked.

Lineage

The trunk writer writes each landing's lineage note itself, from the colony's own record, as it lands the change. Every landed commit carries FT-* trailers and that JSON note under refs/notes/firetrident: the intent, the rule and who approved it, the agent and model, every decision with its probability, the checks, what the agent did not verify, and the exact files read and written, with their blob ids. Any git client can read it, and the showcase colonies need no account. Each note also says how its author and model are known: a model FireTrident's own agent called is observed, with its calls and tokens; an external agent's model is declared, as the agent named it. Each commit landed since notes were sealed (2026-10-14) carries its note's SHA-256 as its last trailer, FT-Note, so a note edited after landing no longer matches its commit: ft verify <colony> checks it, and so do a stock clone and scripts/verify_note.mjs, a short Node script. Agents can leave a one-line lesson with a change; it reaches later agents, labeled with its author and model, only after its change certifies green or a person approves it. The landing page shows a live sealed note and how to check it again with stock git. With a signing key set, the trunk writer also signs each commit it builds (Ed25519, over the note's digest, the tree and the parents) and publishes the key at /.well-known/firetrident-keys.json, so a check says who wrote the note, not only that it is intact. The note lives in git and outlives the agent and its machine: nothing has to be awake to answer why.

Model spend

Each colony prices its own model calls as they happen (its agents, review, the contest judge, the conflict resolver) at Workers AI list prices, in total, by layer and per landed intent, from the tokens it counted: the top bar, ft status and GET /api/colonies/:id/metrics show it as model calls this platform made (an outside agent's own model spend is not on it). A person can cap a colony's spend with a reserve kept for review (ft spend-cap <colony> <usd> --review-reserve <usd>): each call is reserved before it starts, and at the cap the colony pauses itself, so nothing lands on a skipped review. Where FT_INTENT_SPEND is on, each intent's own calls are priced too (GET /api/colonies/:id/intents/:id/spend, the Intents tab, ft intent show).

The review policy

Review reads one policy per colony; its defaults are DEFAULT_POLICY in packages/worker/src/decide/policy.ts. A person changes them with POST /api/colonies/:id/decide/policy (admin token), and each number is clamped to its range.

Setting Default What it does
enabled on Runs the review pipeline on every proposal; off, only protected paths still reach a person
deterministic on Lets a deterministic proof confirm a change with no model
commentProof on Lets a change that only edits comments or whitespace in existing script files land on a deterministic proof
confidence 0.8 A model layer acts alone only when the answers that decide are at least this confident (|2p − 1| for a yes or no answer)
hit 0.5 A yes or no detector answer at or above this probability counts as a hit
needsHuman 0.5 The probability that a change needs a person must be below this for a model's approval to land it
alertsPerHour 30 Escalations to a person in a rolling hour; past it, one below budgetRiskFloor goes back to its agent (protected paths, goal conflicts and a few others never do)
escalationBatchPerHour 60 With FT_ESCALATION_BATCH, escalations the hourly alert budget cannot send back get a budget of their own, per colony; past it, each still waits for a person, and the batchable ones that escalated for the same reason show as one card: approve all, reject all, or open each
budgetRiskFloor 2 The risk (0 none to 3 high) at or above which an escalation still reaches a person once the hour's budget is spent
autonomyAfter 3 Landings a deterministic proof, a second opinion or a person approved in a region, since its last revocation, before the reflex may land there alone
probation 0.1 and 0.25, after 5 fires A detector overruled (by a higher layer or a person) at least 10% of the time becomes advisory, recorded but no longer deciding; more than 25%, off, no longer asked; once it has fired 5 times
maxAntibodies 60 Matching persisted rejection rules (antibodies) asked per proposal, in one Clef call
llmConcurrency 8 Second-opinion calls in flight at once, per colony (the contest judge has a limit of its own of the same size)
llmPerMinute 120 Second-opinion calls started a minute, per colony and model
goalConflictMinutes, goalConflictLandings 60 and 200 With FT_GOAL_CONFLICT, a landing counts as recent, so a change undoing its lines for another intent waits for a person, for 60 minutes and while it is among the newest 200 landings
intentChainDepth 2 With FT_INTENT_CHAIN_GATE, the third agent-declared intent in a row waits for a person
intentFanout 5 With that gate, the agent-declared intents one agent declares in an hour past these 5 wait for a person
reflexModel Clef The decision model asked first
secondOpinionModels Gemma 4 26B, gpt-oss-120b, GLM 4.7 Flash The second opinion: the first of these from a different model family than the change's author
juryModels Gemma 4 26B, gpt-oss-20b, GLM 4.7 Flash With FT_CONTEST_JURY, the small models seated in place of the contest judge
dangerAllow none Danger classes a person allows without sending each such change to a person, optionally under some paths; a second confirmation is still needed
protectedPaths none Paths only a person may change, at most 50 globs
auditRate 0.03 The share of changes that landed without a person (proof, reproduction, a model or earned autonomy) sent to a person after landing, sampled per confirming layer, 0 to 0.2
canaryRate 0 The share of escalations accompanied by a sealed known-bad change in the human queue to measure what reviewers catch, 0 to 0.2; off by default

People see the ordinary, not only the odd. A share of the changes that landed without a person (3% by default, per confirming layer) is sent to a person after landing and shown in the review queue between escalations; "should not have landed" offers the revert and revokes earned autonomy, and the answers measure each layer with an interval. Seeded known-bad changes (blind canaries), sealed so they never land, can be mixed into the human queue to measure what reviewers catch.

How a colony decides. The colony page names a colony's policy as one of four presets: local development, central development (the defaults above), pre-production or production, or custom with the values that differ, each with one sentence on what lands without a person. Beside it are the last 30 days of landed changes by what confirmed them (deterministic proof, a model, earned autonomy, a person), and every landing card names the rule that confirmed it with the values it used, such as R3: confidence 0.93 ≥ 0.9, p(needs_human) 0.04 < 0.2, approved landings 23 ≥ 20. Read it at GET /api/colonies/hono/decides; ft status prints the preset and the split, and ft why the rule. When a change goes to a person, the colony's tests run on it at its base first, and the review card leads with the result against trunk (ft review <colony> --retest <id> runs them again).

How it answers the judging axes

The landing page shows the same table (packages/web/src/landing/axes.ts).

Axis How FireTrident answers it Check it
Concurrency Read-set validation: a change lands only if every file it read is still what it read, so up to 200 proposals fold into one trunk cycle with no lock and no rebase. Replay 2,000 agents landing 6,606 changes
Coordination Decaying claims: agents read the claims and needs other agents leave on the code, and each chooses its own work from the goals people set, with no queue and no one assigning it. Replay the Hono run
Context Lineage notes: every landed commit carries a JSON note in git (the intent, the rule and who approved it, the agent and its model, every decision, the files read and written), sealed by its SHA-256 in the commit's FT-Note trailer and signed. Read the newest note with stock git: git clone https://firetrident.com/git/byo-demo.git && cd byo-demo && git fetch origin refs/notes/firetrident:refs/notes/firetrident && git log --notes=firetrident -1
Review Deterministic proof first, then decision models, a second model from another family and a person, each only when the cheaper layer is unsure; every landing names the person answerable for it, or says no person. See a proof-path landing
Conflicts Text merge lands edits to different lines of one file; a change that cannot merge goes back naming the landing that beat it and quoting that landing's diff and the contested lines, so the agent repairs it without reading trunk again. Run the text merge in your browser

How git's ideas map

Git platform FireTrident
Repository A colony: a trunk repository in Artifacts plus the coordination state around it (the field of marks)
Branch, worktree A workspace: an Artifacts fork leased to one agent with a 2-hour token scoped to that fork, revoked when the fork is reassigned; no token an agent holds can write trunk
Issue, assignment An intent with a predicted footprint, taken by agents by priority, age and the claim leases on its files
Pull request A proposal: write set, read set, evidence, and what was not verified
Code review The review pipeline: proof, Clef, a second model, a person; persisted rejection rules remember every rejection
Merge queue Lanes per region of the code, path-disjoint batches taken greedily in priority order; one commit per batch, and each cycle's batches pushed to trunk together
Merge conflict A change stale only on files it wrote is merged line by line when the edits do not overlap (text merge); otherwise it goes back naming each file that changed under its reads or writes, with the version it read and the version on trunk, or, with the conflict resolver on, a model is asked to merge both, the merge is checked against the clean merge, and it goes through review like any change
Competing pull requests for one issue Contest mode: up to four agents race one intent; one lands, the others stay in its lineage as alternatives
"Blocked: the issue is wrong" escalate: the agent reports it and the intent waits for a person to amend, withdraw or dismiss
Protected, always-green branch certified: moves only to trunk commits on which every test file certification could run passed; deploy and pin from it
git revert ft revert: a person undoes a landing, or one proposal of it, as a new commit, refused when work landed on top; its intents come back with the reason
Contribution stats ft census [<dir>]: any git clone, offline, credits commits, lines added and lines still alive to coding agents, bots or people, each sealed by an intact lineage note, claimed by a trailer or identity, or inferred from a merged agent branch
Codemod A recipe (on staging, a rename across 212 files landed while 30 agents held edits: none came back, where stock git conflicts on all 30): ft recipe <colony> rename <old> <new> --scope <glob> lands a mass rename as ordinary commits and applies it to every change still in flight, so no agent is sent back
git blame ft why: the lineage of any line, from git notes, skipping formatting-only landings, following moved code, and saying whether each landing still holds

What each mechanism buys

Most of FireTrident's mechanisms sit behind a flag, and most were measured with the flag off and on. Each row says where: PRODUCTION is the live service, PREVIEW a preview deployment of the same code with its own Durable Objects, SIMULATED the simulator driven by Hono's history. It gives the number the mechanism exists to move, that number with the mechanism off and on, and what it costs. Three mechanisms cost more than they earned where they were measured (asynchronous publishing, import repulsion where nothing contends, and the contest jury), and all three are off in both configs (Flags lists them all).

Mechanism Run Metric Off On Verdict
Import-name revalidation (FT_REVALIDATE) PREVIEW 2026-10-13-round2: 30 changes import Hono from src/hono.ts, then a landing adds an export to it changes sent back stale 30 of 30; σ peaked at 29 and claim-lease exclusion held the region back 14 times 0 of 30; all 30 landed on their first proposal Earns: no rework. Since 2026-10-14 it also requires each file the change read to have only gained top-level declarations since (a changed statement sends the change back naming its line); what a new declaration does at load time is not checked, and certification is the backstop; off in production
Text merge (FT_TEXT_MERGE) PREVIEW 2026-10-14-round5: two agents edit different lines of one file from the same trunk the second edit sent back stale landed as a line-by-line merge that holds both edits Earns. Two edits of the same line still end with one sent back, naming the hunk
Insertion merges (FT_MERGE_INSERTIONS) PREVIEW 2026-10-14-round7: two agents each append one line at the same place in one file, from the same trunk the second append sent back, naming the landing that beat it (its intent, agent, model and commit) both landed, merged by the insertion rule Earns
Conflict resolver (FT_RESOLVER) PREVIEW 2026-10-14-round6 (checks/resolver.log): two edits of one line from the same trunk the second edit sent back naming the hunk; its intent reopened merged with the first by one model call, both edits kept, and landed Earns, for one model call
Goal-conflict check (FT_GOAL_CONFLICT) PREVIEW 2026-10-14-round6 (checks/goal_conflict.log): three agents each move one backend to a different language changes that undo another goal's landing all three landed; the last silently won the first landed; the other two waited for a person, each naming the landing it would undo Earns. It compares lines, not meaning
Call budget (FT_AGENT_CALL_BUDGET) PREVIEW 2026-10-14-round6 (flood-off.json, flood-on.json): 16 greedy MCP sessions poll inbox without wait beside 4 honest agents, 120 s greedy calls that reached the colony 56,450 7,974; 63,444 of 71,418 were answered 429 Earns: the honest agents landed 120.5 a minute with it and 123.5 without, none refused
Inline changes (FT_INLINE) PREVIEW 2026-10-13-round4: 5,000 synthetic agents in one colony landings a minute 1,821 on the git path; 5.1 s trunk cycles, 3.9 s of each reading blobs from workspaces 3,842; 2.8 s cycles, time to land p50 10.7 s against 19.1 s Earns: twice the trunk writer's throughput
Asynchronous publishing (FT_ASYNC_PUBLISH) PREVIEW 2026-10-13-round4: 5,000 synthetic agents with inline changes landings a minute 3,842; time to land p50 10.7 s, p90 14.7 s 3,776 and 2,759 in two runs; p50 8.0 and 8.2 s, p90 20.8 and 28.1 s Costs more than it earns at this scale: trunk cycles fell from 2.8 s to 1.8 to 2.5 s, but landings did not rise and the slowest waited longer. Off in production
Group commit (built in, no flag) PREVIEW 2026-10-12-g1, against the serial trunk writer on PRODUCTION (2026-10-12), same driver and workload: 200 synthetic agents landings a minute 126; time to land p50 54.3 s 690; p50 2.9 s Earns 5.5 times the landings. At 1,000 agents (515 a minute against 138) the colony object saturated, 816 of 9,927 calls failing, until the scale fixes
Fading claim leases and co-change learning (FT_LATERAL_INHIBITION, FT_COCHANGE_WEIGHT) SIMULATED 2026-10-13-papers: Hono's history, 1,000 agents, group commit, co-change weight 2, every returned change redone in full; mean of 10 seeds share of agent work redone 45.9% with plain optimistic claims, at 205.1 landings a minute; exclusive locks: 34.8% at 51.9 30.5%, at 175.2 landings a minute Earns: less rework than locks at 3.4 times their landings. Costs landings: the claim-lease exclusion alone costs 7.2% of them
Import repulsion (FT_IMPORT_WEIGHT), where work contends SIMULATED 2026-10-13-papers: as above, weight 1 share of agent work redone 30.5%, at 175.2 landings a minute 16.2%, at 158.0 A trade: about half the rework for 9.8% fewer landings, in a best case: the simulator's reads are exactly the import edges
Import repulsion (FT_IMPORT_WEIGHT), where nothing contends PREVIEW: the Hono rule run, 20 Gemma agents, 0 returns either way (in docs/ARCHITECTURE.md; no log committed) time to zero violations 137 s and 143 s 199 s, at weight 1 Costs more than it earns: where nothing conflicts it is pure cost. Off in production
Trunk certification (FT_TRUNK_TESTS) PRODUCTION 2026-10-12-prod: shortlinks-review, a new project whose 13 intents all landed before certification existed the project's own tests passing on trunk 62 of 67 67 of 67: certification found the 5 failures in 267 ms, and the colony's two repairs made trunk green 67 minutes later Earns
Trunk certification, what it costs PREVIEW, 2026-10-12: two colonies side by side, 6 agents each landing a new test file, 75 s runs (in docs/ARCHITECTURE.md; no log committed) time to land, p50 1.37 and 1.42 s 1.26 and 1.23 s No measured cost: no landing waits for a test run
First red commit search (FT_BISECT) PREVIEW 2026-10-14-round8 (checks/bisect.log): one of the 6 landings since the last green commit broke a test finding the landing that broke it no search found in 3 test runs (267 ms), naming its commit, proposal and intent Earns
Signed lineage notes (FT_NOTE_KEY) PREVIEW 2026-10-14-round9 (checks/signed_notes.log): a landing's commit and note rewritten together in a clone, the FT-Note trailer recomputed to match what a check of the rewritten commit says intact: the digest matches the rewritten note bad signature with the published key; the untouched commit reads intact, signed by its key Earns: a check says who wrote the note, not only that note and commit agree. No measured cost: the median wait to land was 1.8 s on the Hono rule run with signing on
Twin intents (FT_TWINS) PREVIEW 2026-10-14-round9 (checks/twins.log): one MCP session declares "Add rate limiting to /api/links", another "Rate-limit the links API", over the same files the second declaration a second intent for the same work nothing created: the answer names the first (score 1); force: true creates it anyway Earns: no second agent on the same work, at no measured cost (it runs when an intent is declared)
Export guard (FT_EXPORT_GUARD) PREVIEW 2026-10-14-round9 (checks/export_guard.log, coordination-p23-hono*.md): a change removes foo from src/b.ts while src/a.ts imports it; then the Hono rule run, 20 Gemma agents, with the guard on and off the removal; the median time a change waits to land the removal landed and src/a.ts broke; 1.8 s the removal went back naming src/a.ts and foo, and landed with src/a.ts edited in the same change; 2.8 s (958 → 0 in 171.1 s against 131.8 s, one run each) Earns where removed exports break importers, at about 1 s of waiting a landing when every change edits script files; off in production
Tests before landing (FT_PRELAND) PREVIEW 2026-10-14-round10 (checks/preland.log): a change that breaks a test that passes on trunk, on a colony the flag covers and one it does not the breaking change landed; certification went red after landing and opened a repair came back before landing in 63 ms, naming the test and its error; the fixed change landed with the run in its note Earns where a colony names the paths: a broken test never lands. Costs a sealed test run per covered change (bounded at 2 s, fails open); on in both configs since 2026-10-19, for every colony with certification, with testing after landing as the backstop
Quoted acceptance (FT_QUOTED_ACCEPTANCE) PREVIEW 2026-10-14-round10 (checks/acceptance.log): two intents with two acceptance lines each; one change meets both, one meets the first only what the second opinion's approval rests on a yes or no a quoted changed line per criterion, found in the diff the model saw; the change meeting one line came back naming the other Earns an approval a person can audit, at no extra model call (one answer per line in the same call)
Contest jury (FT_CONTEST_JURY) PREVIEW 2026-10-14-literature (checks/bias_judge.log, checks/bias_jury.log): 20 contests between two equal-evidence variants of one change, each shown in both orders contests the deterministic tie-break decided 20 of 20: the single judge called 18 "no clear difference" and preferred the first-shown in 2; median 1.9 s to settle, $0.0001 a contest 13 of 20: a majority of two or three small models from different families decided 7; 19 of 60 member answers were inconsistent across orders; median 4.4 s to settle (max 45 s), $0.0006 a contest Costs more than it earns here: ties fell but not by half, settling took 2.5 s longer at the median and 4.4 times the model spend, on variants that may truly be equal; off in production
Chain gate (FT_INTENT_CHAIN_GATE) PREVIEW 2026-10-14-literature (checks/intent_chain.log): agent A declares an intent and takes it, declares a second while working, agent B takes that and declares a third; then A declares past its fan-out the third agent-declared intent in a row, and the one past an agent's fan-out taken at once; every take still says which agent declared the intent, its model and the chain depth held as open reports of kind chain, skipped by takes, listed for a person, released by a dismissal Earns a person's look at a chain of agents writing each other's tasks, at no model cost; off in production until a colony asks for it
Testing after landing, not before (group commit; certification, FT_TRUNK_TESTS) SIMULATED 2026-10-12 (sim-history-test30s-equal-rework.json, run on 2026-10-17 with --baseline-rework 1): Hono's history with 30-second tests. Off is modeled as exclusive locks plus one serialized merge queue that re-runs a change's tests after every rebase; on, each agent runs them in its own workspace and no landing waits for them. Both redo a returned change in full (the first run, sim-history-test30s.json, let the queue redo half) landings a minute 1.9 at every agent count from 10 to 100,000; time to land p50 675.9 s at 1,000 agents. A selective queue that ran only the tests a change reaches would land more than that baseline; the simulator does not model one 164 at 1,000 agents; time to land p50 1.5 s Earns throughput, costs rework: 45% of agent work redone at 1,000 agents against 0.75% in the queue at the same cost per return (FireTrident without the claim-lease exclusion or co-change); equal rework leaves the queue's landings and wait unchanged, since its serial test runs bound it

Accounts

With FT_ACCOUNTS set to on (one switch for the whole deployment, off when absent), people run colonies of their own without a deployment of their own. A person signs in with GitHub on the account page (/account); the first sign-in needs an invite code the operator mints (POST /api/accounts/invites with the admin token, shown once, with a number of uses and an expiry). A person without a code can ask for one on the same page (their GitHub username and email, behind a Cloudflare Turnstile check): the operator gets an email with a signed link to a page that approves or denies the request, and an approved GitHub account opens on its next sign-in with no code (FT_TURNSTILE_SITE_KEY, FT_TURNSTILE_SECRET, FT_INVITE_TO, FT_INVITE_FROM and the INVITE_MAIL send_email binding; without them the page offers no request). A signed-in person connects their own Cloudflare account through Cloudflare's OAuth, and chooses which account when the connection reaches several. Then they can create up to 3 colonies, empty or from a public repository, and mint tokens that each work on one of their colonies with one role: agent (join, take, read and propose, on the API and at /mcp), reviewer (decide changes that wait for a person) or owner (both, plus the colony's settings and tokens). A token lasts at most 30 days and is shown once; a colony has at most 20 live tokens, and its owner can run at most 20 in-platform agents in it. A decision the owner makes signed in is recorded as github:<login>, verified by the GitHub sign-in (ft why and the Why tab say "verified by GitHub"). The owner can delete a colony from the account page: its repositories are deleted from their Artifacts, its agents stop and its tokens stop working.

What bills to whom: a person's colony keeps its repositories in that person's own Artifacts (the namespaces firetrident-trunk, firetrident-ws-0 to firetrident-ws-3 and firetrident-sessions, each created on first use), and its model calls (in-platform agents, review, the contest judge and the conflict resolver) run on that person's own Workers AI; both bill to their Cloudflare account. The deployment's account still pays for the colony's coordination (its Durable Objects and Worker requests), for testing after landing and before it (the project's tests run in Dynamic Workers on the deployment's account), and for issue import. FireTrident itself charges nothing. A connection that did not allow Workers AI runs the colony with the person's own agents over MCP, on their own model bills: in-platform agents are refused (409) with a sentence saying why, and review still runs every deterministic layer (innate checks, proofs, danger patterns, protected paths, goal conflicts); wherever it would ask a model, the change waits for a person instead, with a reason that says so. A deterministic proof still lands a change on its own; nothing else lands without a person. (A deployment without a Workers AI binding keeps its review off, as before.)

A colony with no owner is an operator colony and works exactly as before: the deployment's Artifacts bindings, its Workers AI binding and its admin token. A scoped token never works on an operator colony or on another person's colony, and the deployment's admin and MCP tokens keep working everywhere. With FT_ACCOUNTS off, every accounts route answers 404, the web shows no account link, and nothing else changes; a colony a person created while it was on keeps its owner, and its repositories and models stay out of reach until it is on again: it never falls back to the deployment's account. Who can do what, and how sessions and tokens are kept, is in SECURITY.md.

Flags

Every flag and tuning variable packages/worker/wrangler.jsonc sets, and every flag packages/worker/src/env.ts documents, with its value in the stage config (env.staging.vars) and the production config (the top-level vars). A flag is on, a comma-separated list of colony ids, or off when absent; packages/web/test/docs.test.ts checks this table against the config. A deployment runs the config it was last deployed with: GET /api/about lists the flags the serving build has on. Production also signs lineage notes with the FT_NOTE_KEY secret. The OAuth client ids accounts use (FT_GITHUB_CLIENT_ID, and FT_CF_CLIENT_ID for connecting Cloudflare) are public identifiers set in the configs, not flags; their secrets are Worker secrets. FT_TEST_PUSH_DELAY_MS and FT_LAG_PROBE are test hooks for previews, and FT_OPEN_WRITES is for local development only; none is set in either config.

Flag What it switches Stage Production More
FT_TRUNK_TESTS Testing after landing: the project's own tests run on trunk in a sealed Dynamic Worker, and certified moves to each passing commit on on ledger
FT_CULPRITS A red result names the landings that changed what its failing tests load on on ARCHITECTURE
FT_BISECT The first red commit search: the failing tests run alone at earlier commits, halving the range on on ledger
FT_PRELAND Tests before landing: the test files a change reaches run on its base before it lands on on ledger
FT_RED_BRAKE The red brake: while trunk is red, its repair goes first and changes to what the failing tests load wait for it (15 minutes at most) on on ARCHITECTURE
FT_INLINE Inline changes: a proposal may carry its files' contents instead of a pushed commit on on ledger
FT_VIRTUAL_CHECKOUT Virtual checkouts: in-platform agents read trunk object by object and propose inline on on ARCHITECTURE
FT_ASYNC_PUBLISH Asynchronous publishing: the trunk writer records landings and pushes git beside its cycles off off ledger
FT_TEXT_MERGE Text merge: a change stale only on files it writes lands when each merges cleanly line by line on on ledger
FT_MERGE_INSERTIONS Insertion merges: two insertions at the same place land as their union on on ledger
FT_RESOLVER The conflict resolver: one model call merges overlapping hunks, then review on on ledger
FT_REVALIDATE Import-name revalidation: a change stale only through files it read lands when the names it imports still hold off off ledger
FT_ALREADY_ON_TRUNK A change whose content is already on trunk closes without a commit instead of going back, when it read those files at trunk's version or not at all; one that read them at an older version goes back as a stale read on on ARCHITECTURE
FT_RETURN_HUNKS A returned change quotes the diff of the landing that beat it on on ARCHITECTURE
FT_HEADS_UP Every MCP reply to an agent holding work says what landed under it and what waits ahead on on try-it
FT_DELETION_GUARD A change that deletes a file another trunk file imports goes back on on ARCHITECTURE
FT_EXPORT_GUARD A change that stops exporting a name another file imports goes back off off ledger
FT_GOAL_CONFLICT The goal-conflict check: a change undoing a recent landing for another intent waits for a person on on ledger
FT_QUOTED_ACCEPTANCE Quoted acceptance: a model's approval counts only with a quoted changed line per acceptance line on on ledger
FT_REVIEW_VIEW The review view: FireTrident checks acceptance lines that name an export, a signature, a type or a file itself; the second opinion sees whole files for the rest on on ARCHITECTURE
FT_INHIBIT_STRONGEST Lateral inhibition by the strongest single claim on a shared file, not the sum, so an inhibition lasts the same however many files overlap on on ARCHITECTURE
FT_AGE_CAP Caps the age term in take (at 4), so co-change and import repulsion still matter for old intents on on ARCHITECTURE
FT_REPRODUCE Review by reproduction: a declared recipe is replayed, and only what differs is reviewed on on ARCHITECTURE
FT_ESCALATION_BATCH Escalations past the hourly budget that share a reason are reviewed as one batch on on results
FT_PERSON_WAIT A change waiting for a person gives up its claim leases, so other agents can work its files on on results
FT_CONTEST_JURY A jury of small models from different families in place of the contest judge off off ledger
FT_INTENT_CHAIN_GATE The third agent-declared intent in a row, or one past an agent's hourly fan-out, waits for a person off off ledger
FT_TWINS Twin intents: the same need declared again in other words returns the first on on ledger
FT_MEGAFILE The megafile alarm: a fast-growing shared file is held and split on on results
FT_FIELD_GUIDE Lessons: a one-line lesson reaches later agents once its change certifies green on on results
FT_LESSON_SCOPE Lessons are ranked by their files and dropped once every file they cover has changed on on ARCHITECTURE
FT_MODEL_STEPUP After two returns, an intent's next attempt uses the stronger model on on ARCHITECTURE
FT_HEDGE A model call with no answer after its wait goes out once more; the first answer wins on on ARCHITECTURE
FT_INTENT_SPEND Model spend counted per intent on on results
FT_DEFAULT_SPEND_CAP The spend cap, in dollars, of every colony that has none of its own; a cap a person sets always wins, above or below it 5 5 Model spend
FT_CREDIT_TRAILERS Landing commits carry Co-authored-by: for each agent and Approved-by: for each approver on on ARCHITECTURE
FT_A2A The Agent2Agent door: an orchestrator declares and follows intents over JSON-RPC on on agents/a2a.md
FT_ACCOUNTS Accounts: a person signs in with GitHub, connects their own Cloudflare account and runs up to 3 colonies of their own on it, with tokens scoped to one colony and one role; one switch for the whole deployment on on Accounts
FT_RECIPE_MODULES A person may declare a module recipe the trunk writer runs in a sealed Dynamic Worker off off ARCHITECTURE
FT_AGENT_CALL_BUDGET Each MCP session may make 4 tool calls a second (20 at once after a pause); global on on ledger
FT_COCHANGE_WEIGHT How strongly the co-change map steers takes away from files that change with held ones 5 5 ledger
FT_LATERAL_INHIBITION The claim-lease exclusion threshold at take, as a share of a fresh claim, or off (unset: 0.5) unset unset ledger
FT_IMPORT_WEIGHT Import repulsion at take: claims on a candidate's imports and importers push it away (unset or 0: off) unset unset ledger
FT_PUBLIC_GIT Colonies anyone may clone read-only at /git/<colony>.git hono,shortlinks,byo-demo,scale,order-backend,signed-notes,first-red,mosaic,rename,smuggle hono,shortlinks,byo-demo,scale,order-backend,signed-notes,first-red try-it
FT_PUBLIC_MCP Colonies anyone's agent may ask over the read-only /public/mcp hono,shortlinks,byo-demo,scale,order-backend,signed-notes,first-red hono,shortlinks,byo-demo,scale,order-backend,signed-notes,first-red try-it

How it uses Cloudflare