Development record

Headless agents in parallel coordinate through the shared remote, not conversation

intentplannedminorstandaloneitd-2610170634394993

Press Release

Several headless agents work one repository at once, and none of them needs a conversation to know what the others are doing. Each agent takes a piece of work by a claim on the shared remote, says in a line abcd reads which other change it waits on, and gets a share of the machine and of the model budget from abcd rather than from a message. A change that waits on another is not queued until that one lands, and is rebuilt on top of it when it does, so it meets its conflict once. Any session can run the pass that compares what the records say should happen with what is happening and acts on the difference, so no one process has to stay alive, and every wait has a deadline. One central view shows, at a glance, what every session holds, what it is doing and what it waits on, each line saying how long ago it was last seen, while the detail behind each line stays in that session's own checklist on its computer. No build or drain lane abcd launches works under the person's own forge login: each gets a credential of its own, limited to the repository and the acts its work needs and expiring with it, so a session can neither change the project's settings nor reach anything it was not given.

"Last night one session spent its evening telling four others when a pull request had merged, and a new one had to be asked by message to hold its own," said Maya, an autonomous-development practitioner. "My headless agents never read a message. Now each one writes what it waits on where every other agent already looks, abcd holds it until that lands, and when an agent dies its work goes back to the pool instead of waiting on a promise nobody is left to keep."

Agent-seeded on 2026-10-17 from the evening of 2026-10-16 and a state-of-the-art pass the same night (research note); not yet put to the product thinker.

Why This Matters

abcd's coordination pieces exist but are joined by conversation. Claims (itd-2609091034175565) keep two agents off one record and its files. The load gate keeps preflights from swamping the machine. The merge queue lets one change through at a time. What ties them together on 2026-10-16 was sessions messaging each other: one session asked a new session to hold its records pull request until another landed, and promised to tell four waiting sessions when it merged. A headless agent receives no such message, and a promise lasts only as long as the session that made it.

The same evening showed what a missing deadline costs. The load gate deadlocked for hours between two builds of its own queue rule (iss-2610161634043273), and no wait timed out for eight hours. Two preflights failed on the gate's two-hour limit alone, with every check before it passing (iss-2610161639025702).

Published measurements say the collisions are common, not rare: 19.8% of agent pull requests open at the same time conflicted when one agent made them and 41.7% across agents, and telling an agent what had already landed recovered most of the runs that passed alone and failed together (research note, "Multi-agent coding").

Mechanism

We expect parallel headless agents to stop colliding and stop idling on each other, because every fact they now pass by message (who holds what, what waits on what, whose turn it is, how much budget is left) becomes a record on the shared remote that each agent already fetches and that any session can act on. Shown wrong if, in a measured run of three or more headless agents, the agent minutes lost to conflicts, rebuilds after a dependency landed, and waits that ended in a timeout are no lower than in a run of the same agents with only reservations and the load gate (dcn-2610180720412979: headless agents cannot coordinate by message, so the shipped coordination is the baseline).

Scope Conditions

Holds for agents that can push to the shared remote: people with write access and the cloud sessions they start. An outside contributor reads the records but cannot write one.
Holds for one repository on one forge whose merge queue is the only route to the default branch.
Holds for the machine budget (preflights, race runs) only among agents on one machine, which is all the process table shows. The model budget is kept per computer: sessions on one computer share one pool, and a session on another computer or account draws on that computer's own pool (dcn-2610230757556283).
Holds where the forge can issue a credential narrower than the person's own login, limited by repository and by act (push to its own branches, open a pull request, read), and expiring; GitHub's App installation tokens and fine-grained tokens are the candidates.
Holds for the build and drain lanes abcd launches on its own, which start only where the person's own forge login is absent (a cloud session, a container or a separate user account); on a computer where that login is saved, abcd refuses to launch one. The person's own sessions, those working while the person is away included, keep running on their own computer under their login, and a drain the person starts and watches may count as attended (dcn-2610222025104969, dcn-2610222030477927, narrowed by dcn-2610230710469123).
Holds while at most one minor version of abcd's coordination records is in use at once; a reader meeting a newer record refuses it rather than guessing.

Acceptance Criteria

Given an agent whose branch waits on an open pull request, and says so in a line abcd reads, when it asks abcd to land the branch, then abcd does not queue it while that pull request is open, rebuilds the branch on top of it once it merges, and queues the result.
Given a declared dependency that is closed without merging, cannot be resolved, or closes a cycle, when abcd reads it, then abcd refuses to land the branch and names the dependency and the reason, rather than waiting.
Given an agent holding a claim that stops renewing it, when the claim expires and a delay has passed, then another agent can take the work, and a push or tag abcd makes for the first agent under its old claim is refused because it carries a renewal that is no longer a fast-forward, and a queue entry is refused by a re-read of the claim made just before it (a window of one call, stated, not claimed closed).
Given three headless agents on one machine with a budget of two preflights, when all three reach their preflight at once, then two run and the third waits, and no wait lasts beyond its stated deadline without ending in a named refusal.
Given the session running the coordination pass is stopped mid-pass, when another session runs the pass, then it reaches the same decisions from the records on the remote alone, with nothing lost.
Given two agents running different versions of abcd's coordination records, when they read each other's records, then neither waits on the other in a cycle, and the one meeting a newer format than it knows refuses with a message naming the version.
Given several sessions on different computers, each keeping its own checklist locally, when the person or any session opens the central view, then it shows one line per session (what it holds, its one-line state, what it waits on, when it was last seen) built from the short lines the sessions published, with no program having to stay running.
Given a session that changes what it holds or waits on, when it next writes its checklist, then it publishes its short line only after the checklist is written, and publishes nothing when nothing in the line changed.
Given a session that stops without notice, when the central view is opened, then its line reads as live, then as not seen for a stated time, then as work another session may take over after a delay, then it is gone; it never reads as working once its renewals have stopped.
Given an autonomous session started by abcd, when it pushes, opens a pull request or reads the forge, then it does so under a credential issued for it alone, limited to the repository and the acts its work needs and expiring with it, never under the person's own login; and when it tries an act outside that set (changing a repository setting or variable, deleting a branch under a protected prefix, reaching a repository outside its token's reach), the forge refuses it (narrowed per dcn-2610180720415625: a token that can push can delete an unprotected branch).
Given the person's own login holds admin rights on the repository, when an autonomous session runs, then nothing the session can reach carries those rights, so a setting only the maintainer may change (the reservation cap among them) stays out of its reach.
Given a computer where the person's forge login is in a place abcd checks (the forge CLI's saved login, a token variable, a stored-credential file naming the host), when abcd is asked to launch a build or drain lane there, then abcd refuses to launch it, names each place it found a login without reading or printing the login, and says what it cannot see (a keychain-only login, an SSH key); and given a cloud session, a container or a separate user account with none of them, the lane starts with its own App token, which travels through abcd's own credential channel and so never trips the check. The person's own sessions are not checked (dcn-2610230710469123).
Given the repository sets a sub-agent budget of eight and two sessions are running on one computer, when both start sub-agents, then together they never hold more than the budget, and a session that finds the budget spent waits for a slot under a stated deadline rather than starting one; a session on another computer draws on that computer's own pool (dcn-2610230757556283).
Given an agent about to re-submit a branch after a change it overlaps with has landed, when abcd rebuilds it, then the agent is given a summary of what landed since its base.

SOTA

Surveyed 2026-10-17 against primary sources (research note):

Kubernetes controllers and leases, Chubby sequencers: mature. Adopted as the pattern: coordination is a pass that compares wanted and current state held in shared records, a claim is a compare-and-swap with an expiry and a generation number that a later act re-checks, and a dead holder's claim is retaken only after a delay. The shared remote already gives abcd the compare-and-swap (a push that is not a fast-forward is refused).
Job queues with timeouts (Faktory, Temporal): mature. Adopted: work comes back by timeout, never by noticing a death, and every wait has a wait-to-start limit, a per-attempt limit and a heartbeat.
Merge queues and dependency lines (GitHub merge queue, Mergify Depends-On:, git-spice, Aviator): mature. GitHub's merge queue stays the only route to the default branch. The dependency line and the footprint routing are the parts abcd has to add, because the queue it uses reads neither.
Multi-agent coding products (Claude Code agent teams, Copilot's cloud agent): young. Agent teams coordinate through a shared task list but are bound to one session on one machine, so they cannot carry coordination across accounts or into the cloud. Not adopted as the layer.
A coordinator cluster (etcd, a Temporal server): mature but out of scale for one repository. Not adopted.

Path taken: 2. The forge and the shared remote are the native floor (the queue, compare-and-swap pushes, branches cloud sessions can push), and the pass, the dependency line, the generation number and the budgets are bespoke to abcd's records, behind a seam.

Carried in from itd-2610240850336695, its Decision 19 (product thinker, 2026-10-24). When sessions push under a credential of their own, the repository gains a ruleset refusing non-fast-forward pushes on every branch, with a bypass for the person's admin role: a session and abcd then cannot force-push anywhere, and the person still can, through gh or the forge's web interface. Until then the person's grant ships with the force-push stop on feature branches resting on this machine's pre-push hook and the guard.

The bundle gains a third member (product thinker, 2026-10-24). The person's grant, itd-2610240850336695, joins the autonomous-agents bundle with this intent and the checklist, so its force-push stop lands with this intent's credential split and the all-branch ruleset above.

Open Questions

All resolved: answered on 2026-10-18 by the planning prep (facilitator, each a decision record), on 2026-10-22 by the product thinker and on delegation, and at the product thinker's walk and sign-off of 2026-10-23.

Who runs the pass: any session on demand, before it acts; no timer lease (dcn-2610180720366282).
Where "waits on" lives: a Depends-On: line in the pull request body, mirrored as a hint on the status line (dcn-2610180720362692).
Merge or restack: merge, restacking only after a hand squash or rebase merge (dcn-2610180720369860).
The machine budget: the load gate's slots, weighted per job (dcn-2610180720376153). The model budget: shared across sessions (dcn-2610222025116937, the product thinker's reversal of dcn-2610180720379757), per computer (dcn-2610230757556283).
The credential: a GitHub App token minted for the person, eight-hour expiry (dcn-2610180720379765, dcn-2610180723332655); the App registered once in the browser (dcn-2610180720389628); shipped with the coordination (dcn-2610222025116835).
The release cut: the announcements intent's release reservation, no new lease (dcn-2610180720382472).
"I am merging, hold": a hold is a reservation; the announcement informs (dcn-2610180720389352).
Push rate: renewals hourly, the line only on change, back-off on refusal (dcn-2610180720390166).

Which unattended runs the login check covers: settled 2026-10-23 by the product thinker (dcn-2610230710469123, decision 12). Only the build and drain lanes abcd launches on its own; the person's own sessions keep the login they run under.
How a session's token is issued: settled 2026-10-22, on delegation (dcn-2610222048069284). A user access token from the device flow, so no client secret ships anywhere; the refresh token stays on the person's computer, outside every session; each launch gets an eight-hour token, and a cloud session's pushes stop when it lapses, queued for the person's return.

How far the shared model budget reaches: settled 2026-10-23 by the product thinker (dcn-2610230757556283, decision 13). Per computer: a pool kept on that computer, as the load gate's slots are, with no pushes; sessions on other computers or accounts have pools of their own.

Decisions

The draft is split (2026-10-17). The product thinker confirmed the decomposition as proposed: this intent holds the capability alone. The trust rule (every wait has a deadline, a claim's generation number is re-checked before a push, queue or tag, and a reader refuses a newer coordination record) becomes an ADR at planning, and the stance that coordination lives on the shared remote, never only in conversation, becomes a principle. The table is in the decomposition-calibration note under this date.
Ownership with take-over lives here, and the check before an unattended run does not (2026-10-17). The product thinker chose to keep the check of what could block a long run, which asks every session what only the person can unblock, in the per-session checklist draft, done by asking sessions by message. Work owned with an expiry, and taken over when its holder stops renewing, stays in this intent; it had one defensible home, so it was recorded rather than asked. The checklist draft is where a session keeps its own state; this intent is what sessions share.
The central view is one short published line per session, with the details kept locally (2026-10-17). The product thinker asked for a central place to see at a glance what is taken and worked on, with each session's details kept within that session so they survive compaction, and asked for a state-of-the-art pass on the link between the two (research note, "The central view and each session's detail"). Offered a short line per session with the details local, or the full checklist uploaded as well so another computer could resume a dead session, they chose the short line: each session's checklist on its own computer is the source of its detail, the session publishes one short line about itself when that line changes, the claim renewal it already makes shows it is alive, and the view is every line put together, built by whoever reads it. A dead session's unpublished steps are lost; full uploads can be added on top later.
This intent supersedes the register draft (2026-10-17). The register draft (itd-2609150819440345) stated the problem this intent answers: who holds what was settled only in conversation. Its want, a central place to see who holds what, is decision 3's view, and its claim branch shipped as reservations. Its helper program on each machine, reachable over a private network to show work not yet pushed, is dropped: it needs a process left running, which decision 3 avoids. It can be raised again as a new idea.
Autonomous sessions never use the person's own forge login (2026-10-17). The product thinker ruled that autonomous sessions work under a weaker credential of their own, given on a need-to-know basis, and that this belongs to this intent and to the autonomous-agents bundle. It was found that day that every session on the machine used the maintainer's own gh login, which holds admin rights on the repository, so any session could change a setting meant for the maintainer alone (the reservation cap, captured the same day).
The central view says what each session is actually doing (2026-10-17). Restated from the product thinker's ruling relayed by the checklist draft's session: the person must never wrongly believe agents are working or waiting. A line's state is therefore derived from what the machine and the remote can see (the renewal, the process, the last commit), and what an agent writes about itself is a hint beside it, because agents' own status reports lag.

Unattended runs happen only where the person's forge login is absent (2026-10-22, C1). The product thinker chose a real guarantee, set up once, over saying plainly that the login is still within reach (dcn-2610222025104969). abcd checks for a saved login before an unattended run starts and refuses where it finds one (dcn-2610222030477927, facilitator).
Only the short line is shared now; full checklist uploads come later (2026-10-22, C2). Settles the two rulings of 2026-10-17 in favour of later and keeps decision 3 as written (dcn-2610222025114805). The later uploads are itd-2610222029228127.
Agents' own App tokens ship in the same release as the coordination (2026-10-22, C3). The person registers abcd's GitHub App once in the browser before that release is usable (dcn-2610222025116835).
The model budget is shared across sessions (2026-10-22, C-confirm). A typed reversal of dcn-2610180720379757 and of the product thinker's 2026-10-10 answer "each abcd run" in itd-2610100704270254: the budget is one pool every session draws on, and one busy session can slow the others, which the product thinker accepted (dcn-2610222025116937). The press release keeps "a share of the model budget".
The trust rule and the stance are written (2026-10-22). The trust rule is adr-2610222026262980, proposed until the plan's sign-off, then a brief invariant; the stance is the principle coordination-lives-on-the-shared-remote.
Only abcd's own helpers run away from the person's login (2026-10-23, narrowing C1). The product thinker ruled that the build and drain lanes abcd launches on its own must run where the person's GitHub login is absent, while the person's own sessions working while they are away keep running on their own computer under their login, and a drain the person starts and watches may count as attended (dcn-2610230710469123). Decision 7's guarantee therefore covers abcd's launches, not the person's own sessions, and the login check runs before a launch only.
The product thinker's walk and sign-off (2026-10-23). The model budget is per computer: sessions on one computer share one pool, and a session on another computer or account draws on its own computer's pool, narrowing decision 10's "shared across sessions" and the scope condition that had it span an organisation's accounts. The ten person-visible stories stand, the budget story in its per-computer form, and so does the cloud run's eight-hour key, which the product thinker kept after asking why eight (GitHub sets eight hours for an app's user access token, and its renewal stays on the person's computer). The technical list is accepted, and the press release, mechanism, grounds, scope conditions and reason for doing it now are signed off as written (dcn-2610230757556283).

Audit Notes

Empty. Populated by intent-auditor when intent moves to shipped/.

Grounds

pursued: parallel headless agents stop colliding and stop idling on each other once who holds what, what waits on what, whose turn it is and how much budget is left are records on the shared remote rather than messages; shown wrong if a measured run of three or more headless agents loses no fewer agent minutes to conflicts, rebuilds after a dependency landed and waits that ended in a timeout than the same agents with only reservations and the load gate. Occasioned by the evening of 2026-10-16, when one session relayed merges by message all night and the load gate deadlocked for eight hours with no deadline.

Frontmatter

id	itd-2610170634394993
type	intent
lifecycle	planned
kind	standalone
severity	minor

.abcd/development/intents/planned/itd-2610170634394993-several-headless-agents-work-one.md
open on GitHub ↗ · commit history ↗

References13

itd-78abcd Knows What to Build First — Even When It's Something Smallrelated
itd-82`abcd drain` fixes the issues that need no decision, and hands the rest back by kindrelated
itd-115A Ready PR Merges Without Ever Wedging BEHINDrelated
itd-148Every change starts in its own worktree in abcd's store: the primary checkout is a read-only surface, and abcd blocks mutations there for every session but a declared coordinatorrelated
itd-2609091034175565Before an agent starts on an item, it reserves it on the shared remote, and everyone who works on the project sees the reservationbuilds on
itd-2609150819440345Which session holds which worktree, branch or record is coordinated entirely by conversation, so every new session repeats a handshake that nothing records. A session joining work in progress has no way to ask what is already claimed: it messages the peers it can see, waits for replies, and rebuilds a picture that the sessions before it had already built and did not write down. One measured encounter cost four messages and about fifteen minutes before any work began, and the picture it produced is not durable, so the session after that pays again. The convention that a diff you did not make is a peer's work depends on knowing who the peers are and what they hold, which is precisely the thing no artefact carries. The repository already records this gap for the narrow case of detecting a peer session before mutating git state; the wider case is claim rather than presence, and the two want the same substrate. Whatever holds it should be as cheap to write as it is to read, because a coordination record nobody updates is worse than the chat it replaced.supersedes
itd-2609151838312703Sessions under any account, on any machine or in the cloud announce what they are doing through short fixed-form announcements on the shared remote, a person reads everyone's status with one command, and what is really a hold stays a reservationbuilds on
itd-2609201916151817One verb takes a READY intent to delivered, and refuses while a decision is openrelated
itd-2609201925079472An autonomous run paces itself by default, and one flag sets the pacerelated
itd-2609221656373558Two sessions share one run, and the run measures which way of dividing the work is bestbuilds on
itd-2610100704270254An abcd run sets how many sub-agents it keeps alive by the models they run onrelated
itd-2610170638184486Every session keeps a checklist on disk, so no run stalls and no stall spreadsrelated
itd-2610222029228127Every session's checklist reaches a shared copy and the phonerelated

Referenced by18

adr-2610222026262980Coordination between headless agents is bounded by deadlines, fenced by the claim's tip, version-checked, and done under each session's own credentialrelated
adr-2610222026265719A session's checklist names a credential by its kind, scope and expiry, never its value or anything that retrieves itrelated
iss-2609100519122086Which session holds which worktree, branch or record is coordinated entirely by conversation, so every new session repeats a handshake that nothing records. A session joining work in progress has no way to ask what is already claimed: it messages the peers it can see, waits for replies, and rebuilds a picture that the sessions before it had already built and did not write down. One measured encounter cost four messages and about fifteen minutes before any work began, and the picture it produced is not durable, so the session after that pays again. The convention that a diff you did not make is a peer's work depends on knowing who the peers are and what they hold, which is precisely the thing no artefact carries. The repository already records this gap for the narrow case of detecting a peer session before mutating git state; the wider case is claim rather than presence, and the two want the same substrate. Whatever holds it should be as cheap to write as it is to read, because a coordination record nobody updates is worse than the chat it replaced.related
iss-2610140638074587The load waiter's one-waiter-at-a-time hold, ~/.abcd.noindex/load-wait.json, lives in the caller's own home, so it is per account, not per machine as the help and the LOAD rule call it. A second macOS account on the same machine (a colleague joining this machine) runs its own waiter against its own home and never sees the first account's hold, so two accounts' gated preflights are admitted together whenever the load and race-run conditions are open at once, which is exactly the moment between a preflight's start and its race step. Sharing the hold file across accounts is not a fix: a file another account can write would let one account hold every other account's gate shut, which the security rule forbids.related
iss-2610161634043273The load gate's queue orders waiters by pid, so a waiter with a high pid starves once the machine's process ids wrap. machineload.QueueAhead counts another waiter as ahead when its pid is lower than this one's. After a reboot on 2026-10-16 the ids wrapped: waiters started between 16:07 and 17:26, with pids 50460 to 71218, all queued ahead of one started at 16:04 with pid 96274. That waiter could only wait out its timeout while lower pids kept arriving. The docs and the LOAD rule promise one waiter at a time in queue order.related
iss-2610161639025702Preflight throughput sets the pace of all work on this machine, and nothing keeps it in bounds. On 2026-10-16 the load gate admitted one make preflight at a time, each took about 40 minutes, and about 20 waiters were queued across seven sessions. Every reviewed branch had its own preflight, so a seven-step feature needed seven full runs, and records-only branches paid the same full cost as code. Sessions waited hours, and the queue's ordering after the reboot starved late waiters (fixed separately on fix/load-queue-start-order). No rule tells sessions to batch work, and no part of preflight scales its cost to what a change touches.related
iss-2610162306239284The load gate's stand-back window (the open pause plus the start tolerance) is measured from the look, not from the waiter's own re-check read, so a waiter whose path from that read to starting its mark is slow under load (about 2.5 s) discards a concurrent lower-pid opener it did see, and both run their commands, which can bring back two preflights each waiting on the other's running waiter; no test pins the window's bound.related
iss-2610262037257443itd-2610170634394993 calls the hold on the shared remote a claim; in 27-implement, a claim is the run-state lock on this machine that keeps sessions apart.related
iss-2610262039043469itd-2610170634394993 puts agents' work claims on the shared remote; 04-universal-patterns puts multi-agent claims in .abcd/coordination/related
iss-2610262039059270itd-2610170634394993 proposes a central view of what every session is doing; 39-status already ships /abcd:status as that viewrelated
iss-2610262042513525itd-2610170634394993 and itd-2609151838312703 each define the one view of what every session is doingrelated
itd-2609091034175565Before an agent starts on an item, it reserves it on the shared remote, and everyone who works on the project sees the reservationrelated
itd-2609151838312703Sessions under any account, on any machine or in the cloud announce what they are doing through short fixed-form announcements on the shared remote, a person reads everyone's status with one command, and what is really a hold stays a reservationrelated
itd-2609221656373558Two sessions share one run, and the run measures which way of dividing the work is bestrelated
itd-2610222029228127Every session's checklist reaches a shared copy and the phonebuilt on by
itd-2610222215485265abcd drain --drive works through the ledger from a plain terminalrelated
itd-2610241331131356The session view reads live agent state from a workspace managerbuilt on by
spc-2610230758581403several-headless-agents-work-oneimplemented by

mentions38

coordination-lives-on-the-shared-remoteCoordination lives on the shared remote, never only in conversation
dcn-26101807203626922026-10-18 — A dependency is a Depends-On line in the pull request's body (facilitator-on-delegation, itd-2610170634394993 planning prep): a branch's wait on another change is written as Depends-On: #N, which land writes from the agent's declaration and the pass enforces, and the session's short status line mirrors it as a hint only; a field on the claim is not used, since a reservation is per record and per person while a dependency belongs to a change, and the line's exact spelling is plumbing for the brief (grounds: docs.mergify.com/merge-protections/builtin; Zuul's Depends-On footer; itd-2609091034175565)
dcn-26101807203662822026-10-18 — The coordination pass runs on demand (facilitator-on-delegation, itd-2610170634394993 planning prep): land, build, drain and status run the pass from the records they have just fetched before they act; there is no timer lease and no process that must stay alive, and every deadline and expiry is derived when the records are read, as a reservation's release already is (grounds: the draft's research note on controllers; kubernetes.io/docs/concepts/architecture/controller; brief invariant 7; itd-2609151838312703 decision 14; itd-2609091034175565 decision 13)
dcn-26101807203698602026-10-18 — A waiting branch is rebuilt by merging, not restacking (facilitator-on-delegation, itd-2610170634394993 planning prep): once its dependency lands, the dependent branch takes the default branch merged in and is never rewritten, because the merge queue lands by merge so the dependency's commits keep their ids, and a restack would break the reachability of resolved_by stamps (RS002, RS003); a restack is used only when the dependency was squash- or rebase-merged by hand, which the review ruleset allows; each rebuild needs a fresh preflight receipt and so takes a load slot (grounds: .abcd/work/rulesets/main-protection.json; main-review.json; AGENTS.md RS002 and RS003; git-spice)
dcn-26101807203761532026-10-18 — The machine budget is the load gate's slots, weighted per job (facilitator-on-delegation, itd-2610170634394993 planning prep): preflights, race runs and every other heavy job draw on one pool, the load gate's existing slots (load.preflights), each job weighted, with a dead holder's slot reclaimed as it is now; no second pool is added (grounds: principles/one-canonical-primitive.md; airflow.apache.org pools; internal/core/implement/load_slots.go)
dcn-26101807203797572026-10-18 — The model budget stays a fixed count per abcd run (facilitator-on-delegation, itd-2610170634394993 planning prep): the sub-agent budget remains itd-2610100704270254's count per run from the repository's config, neither shared across sessions nor sized from rate-limit headers, since the product thinker ruled 'each abcd run' on 2026-10-10 and agent work is delegated to the host, so abcd never sees the provider's headers; the draft's press release and model-budget scope condition are to be narrowed to match, which is put to the product thinker to confirm because it edits their confirmed text (grounds: itd-2610100704270254; AGENTS.md host-delegated by default)
dcn-26101807203797652026-10-18 — An autonomous session's credential is a GitHub App token (facilitator-on-delegation, itd-2610170634394993 planning prep): each session gets a token the repository's App mints for it, short-lived and scoped by repository and permission; a fine-grained personal token is not used, because none can be created through an API and none expires with the session (grounds: docs.github.com authenticating-as-a-github-app-installation; docs.github.com managing-your-personal-access-tokens)
dcn-26101807203824722026-10-18 — The release cut's hold is the announcements intent's reservation (facilitator-on-delegation, itd-2610170634394993 planning prep): this intent adds no lease of its own for a release being cut; the merge path already reads the release reservation (grounds: itd-2609151838312703 C7 and decision 2; internal/core/landing/releasehold.go)
dcn-26101807203893522026-10-18 — A hold is a reservation; a merging announcement informs (facilitator-on-delegation, itd-2610170634394993 planning prep): the pass enforces holds only through reservations and reads a merging announcement as information, so the short status line carries no hold field (grounds: itd-2609151838312703 decisions 2 and 4)
dcn-26101807203896282026-10-18 — Registering the App takes one step in the browser (facilitator-on-delegation, itd-2610170634394993 planning prep): creating a GitHub App needs the person on the website once, through the manifest flow, so the draft states it as a step only the person can take, as the checklist draft already lists it, and never promises setup without manual steps (grounds: docs.github.com registering-a-github-app-from-a-manifest; itd-2610170638184486)
dcn-26101807203901662026-10-18 — Pushes stay well inside the forge's rate (facilitator-on-delegation, itd-2610170634394993 planning prep): renewals stay at half the two-hour lease, hourly, the short status line is pushed only when it changes, and a refused push backs off, so ten sessions stay far below six pushes a minute (grounds: itd-2609091034175565; internal/core/claim/renewdue.go; docs.github.com repository-limits)
dcn-26101807203977742026-10-18 — One central-view line per working copy (facilitator-on-delegation, itd-2610170634394993 planning prep): a session in the view is a working copy, keyed on the reservation's existing copy key, since the checkout is the unit of isolation (grounds: itd-2609091034175565 decision 33; AGENTS.md concurrent sessions; internal/core/claim/message.go)
dcn-26101807203979702026-10-18 — The claim's generation number is its tip commit (facilitator-on-delegation, itd-2610170634394993 planning prep): every act goes through a fast-forward push, which is already a compare-and-swap, and a take-over moves the tip, so no separate counter is added; the forge enforces the fence only on a push, so for queueing and tagging the criterion says abcd refuses the act, and whether one atomic push can carry the work branch and the renewal together is left to probe at planning (grounds: internal/core/claim/claim.go; internal/core/implement/loop/reservation.go; Chubby section 2.4; git-scm.com/docs/git-push --atomic)
dcn-26101807204020072026-10-18 — A session's state line is fixed-form (facilitator-on-delegation, itd-2610170634394993 planning prep): the line's state is a stage from a fixed list plus the record ids it waits on, carried on the person's existing abcd-status branch, never free text, and no branch per session is added (grounds: itd-2609151838312703 C3 and decisions 1 and 9; internal/core/claim/stage.go)
dcn-26101807204023612026-10-18 — A session's line carries its own expiry (facilitator-on-delegation, itd-2610170634394993 planning prep): a line is renewed and expires on its own, counted from its first fetch, so a session that holds no reservation still shows as live or gone (grounds: itd-2609151838312703 C9; kubernetes.io node leases)
dcn-26101807204074592026-10-18 — A re-submitting agent is given the merged pull requests that touch its footprint (facilitator-on-delegation, itd-2610170634394993 planning prep): the draft's criterion asking for a summary of what landed becomes the list of pull requests merged since the branch's merge base that touch its footprint, which a test can check (grounds: the draft's research note on multi-agent coding, Xia et al.)
dcn-26101807204129792026-10-18 — The mechanism's baseline is the shipped coordination (facilitator-on-delegation, itd-2610170634394993 planning prep): the falsifier compares a run of three or more headless agents against the same run with only reservations and the load gate, not against agents coordinating by message, which headless agents cannot do (grounds: the draft's Mechanism and Why This Matters sections)
dcn-26101807204156252026-10-18 — Branch deletion is refused by rulesets, not by the token (facilitator-on-delegation, itd-2610170634394993 planning prep): a token able to push can also delete branches, so the criterion that a session cannot delete a branch it did not create is narrowed to the protected prefixes the rulesets already guard, and other branches stay deletable (grounds: docs.github.com permissions-required-for-github-apps; brief invariant 16; .abcd/work/rulesets/reservations-protection.json)
dcn-26101807204156262026-10-18 — Refusing a newer coordination record starts with the release that adds a version (facilitator-on-delegation, itd-2610170634394993 planning prep): readers already shipped ignore an unknown trailer, so the criterion's refusal can hold only from the release that adds a version field, and the criterion says so (grounds: internal/core/claim/message.go; kubernetes.io version-skew-policy)
dcn-26101807204274372026-10-18 — The coordination stance has a bound (facilitator-on-delegation, itd-2610170634394993 planning prep): the principle that coordination never lives only in conversation governs facts one agent relies on from another (holds, waits, turns, budgets); a question put to a person, such as the pre-run blocker sweep the product thinker placed in the checklist draft, may travel by message and lands in each session's checklist (grounds: the draft's decision 2; itd-2610170638184486 scope split)
dcn-26101807205412062026-10-18 — A session's mode shows on its central-view line (facilitator-on-delegation, itd-2610170634394993 planning prep): the line carries the session's state from the checklist draft's fixed set: working; waiting, with what it waits on and when it next looks; or stopped, which is allowed only while the person is present and is flagged. While the person is away a session with work never stops, and one with nothing it can do is waiting with its next look, so no session reads as idle. This follows the product thinker's ruling that the person must never wrongly believe agents are working or waiting (grounds: the draft's decision 6; itd-2610170638184486 modes)
dcn-26101807205480662026-10-18 — A waiting session wakes before half its lease (facilitator-on-delegation, itd-2610170634394993 planning prep): since no process stays alive and a branch is rebuilt only when its agent asks to land, a session waiting on a dependency wakes, through the checklist draft's timed wake, at an interval shorter than half its reservations' lease, so an idle waiter's reservations are renewed rather than lapsing after two hours and being taken over (grounds: itd-2609091034175565 two-hour lease, renewed at half; itd-2610170638184486 timed wake; the draft's take-over criterion)
dcn-26101807233326552026-10-18 — An autonomous session acts on the forge as the person, through the App (facilitator-on-delegation, itd-2610170634394993 planning prep): every commit stays authored by the person, since the attribution gate refuses a machine as author or committer; the session pushes and opens pull requests with a token the repository's App mints for the person, limited to the permissions both the App and the person hold and expiring after eight hours, so its work shows the person's name marked as made through the App; the App's own bot identity is not used, because the forge's who-am-I endpoint does not answer for it, so a cloud session could no longer resolve its reservation holder; this meets the product thinker's ruling of a weaker credential of the session's own, which concerns the credential, not the name (grounds: the draft's decision 5; AGENTS.md attribution; scripts/check-attribution.sh; brief invariant 10; docs.github.com generating-a-user-access-token-for-a-github-app; docs.github.com endpoints-available-for-github-app-installation-access-tokens)
dcn-26101807233425962026-10-18 — The central view is abcd status (facilitator-on-delegation, itd-2610170634394993 planning prep): the view of what every session holds, does and waits on is shown by abcd status, which the product thinker named the people's view of what everyone else is doing; abcd peers keeps the meaning they reserved for it, the sessions running now seen locally and later over a private network, which this intent's decision 4 dropped (grounds: itd-2609151838312703 decision 21; the draft's decisions 3 and 4)
dcn-26101809052838062026-10-18 — The overnight-stall fix ships first, ahead of the coordination intent (facilitator-on-delegation, itd-2610170634394993 planning prep): the fix for the critical overnight stall (an autonomous mode abcd holds, and a stop check that refuses to end a turn with owed work) sits in the checklist draft, which owns a session's modes, waits and stop check; it needs nothing on the shared remote, so it ships as the bundle's first slice, without waiting on this intent, and the security and bug-fix cut waits on that slice alone; this intent then adds what the stall's record asks for across sessions, the idle time a coordinator sees, through the central view's derived state and last-seen time in abcd status rather than in abcd peers as the record's remedy words it, per the decision naming abcd status as the central view (grounds: iss-2610170619247185 remedy; itd-2610170638184486 scope split; the draft's decisions 3 and 6)
dcn-26101809052912972026-10-18 — A declared dependency constrains only the landing (facilitator-on-delegation, itd-2610170634394993 planning prep): a branch that waits on an open pull request is held only from being queued; its merge from the default branch, its fixes, its review and its preflight run now, and only its landing waits for the dependency, so the stop check counts a stacked branch with an open base as owed work (grounds: iss-2610170619247185, second instance; the draft's first acceptance criterion; the decision that a waiting branch is rebuilt by merging)
dcn-26102220251049692026-10-22 — Unattended agent runs happen only where the person's forge login is absent (product thinker's ruling of 2026-10-22, itd-2610170634394993 C1): an agent left to run overnight or while the person is away runs in a cloud session, a container or a separate user account, where the person's saved forge login cannot be reached, so the promise that agents cannot use the person's admin rights is a guarantee, set up once, rather than a caveat that the login is still within reach on their own computer; asked after an example, this was chosen over saying the limit plainly and leaving the login reachable
dcn-26102220251148052026-10-22 — Only the short status line is shared for now; full checklist uploads come later (product thinker's ruling of 2026-10-22, itd-2610170634394993 C2): this intent publishes one short line per session and no full checklist, public or private; uploading a session's whole checklist so another computer could resume it is later work. This settles the two rulings of 2026-10-17 that disagreed, in favour of later, and keeps the intent's decision 3 as written
dcn-26102220251168352026-10-22 — Agents' own limited access ships in the same release as the coordination (product thinker's ruling of 2026-10-22, itd-2610170634394993 C3): autonomous sessions get short-lived tokens for one job from abcd's GitHub App from the first release of this intent, not in a later piece; the person registers the App once in the browser before that release is usable, a step only they can take. This is what makes C1 work: a run kept away from the person's login needs those tokens to push
dcn-26102220251169372026-10-22 — The model budget is shared across sessions, not a fixed count for each abcd run (product thinker's ruling of 2026-10-22, itd-2610170634394993 C-confirm; a typed reversal: reverses dcn-2610180720379757 and the product thinker's 2026-10-10 answer 'each abcd run' in itd-2610100704270254): the sub-agent budget the repository sets is one pool that every abcd session draws on, so the draft's press release keeps 'a share of the model budget' and is not narrowed; the product thinker accepted that one busy session can slow the others. dcn-2610180720379757's narrowing of the press release and the model-budget scope condition is withdrawn
dcn-26102220304779272026-10-22 — abcd looks for the person's forge login before it starts an unattended run, and refuses to start where it finds one (facilitator, on state-of-the-art grounds, applying the product thinker's 2026-10-22 ruling C1 on itd-2610170634394993): before an away-mode run, build or drain starts unattended, and before abcd issues the session a token of its own, abcd checks only signals that carry no secret: the forge CLI's login status for the host by exit code alone, with its output discarded (the CLI prints no token unless asked with --show-token); whether the token variables the forge CLI and git read (GH_TOKEN, GITHUB_TOKEN and their enterprise forms) are set, never their values; and whether the stored-credential files hold an entry for the host (the forge CLI's hosts file and ~/.git-credentials), by the host line alone. It never asks a git credential helper for the host, since a helper answers with the token itself and on macOS may raise a keychain prompt that hangs an unattended start; so a login kept only in a keychain is out of the check's sight, and the refusal says so rather than claiming the machine is clean (brief invariant 16). It refuses to start, naming each place it found a login, and never removes or hides one; the guarantee rests on where the run is started (a cloud session, a container or a separate user account), which abcd states as the person's setup step. The session's own token, issued after the check, never travels in those variables (grounds: cli.github.com/manual/gh_auth_status; cli.github.com/manual/gh_help_environment; git-scm.com/docs/gitcredentials; adr-2610222026262980 rule 4)
dcn-26102220480692842026-10-22 — A session's own token is a user access token from the device flow, and its refresh token stays on the person's computer (facilitator on the product thinker's delegation of 2026-10-14 for technical choices grounded in the state of the art, itd-2610170634394993; keeps dcn-2610180723332655, the person's name marked as made through abcd, which the product thinker accepted in the 2026-10-22 C3 question): the person authorises abcd's GitHub App once through the device flow (a code entered in the browser), which needs only the App's client id, so no client secret is shipped to any machine, and a device-flow token is refreshed without the secret; the refresh token, which lasts six months and is replaced at each refresh, is the only issuing secret, and it is kept on the person's computer in the system's credential store (the macOS keychain, or a file only the person's account can read under ~/.abcd.noindex on Linux), outside every session and on the fence's read-deny list; at each unattended launch abcd on that computer refreshes and hands the session only the eight-hour access token, through abcd's own credential channel; a container or a separate user account on the same computer is handed a fresh token before the old one lapses, and a cloud session cannot be reached after launch, so its pushes stop when its token lapses and its remaining pushes are queued as owed work for the person's return or a relaunch, which the walk states; the token reaches only the repositories the App is installed on, so abcd asks for the App to be installed on the one repository; the installation token stays the fallback behind the forgecred seam, with the commit author still the person, should the device flow be withdrawn (grounds: docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-user-access-token-for-a-github-app; docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/refreshing-user-access-tokens; docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app)
dcn-26102307104691232026-10-23 — The product thinker's ruling of 2026-10-23, restated, narrowing their 2026-10-22 C1 answer (dcn-2610222025104969): only the helpers abcd launches on its own, the build and drain lanes, must run away from the person's GitHub login. The person's own sessions working while they are away keep running on their own computer under their login, and a drain the person starts and watches may count as attended. It settles choice 1 of the coordination intent (itd-2610170634394993) and choice 2 of the terminal-drain intent (itd-2610222215485265), and the login check before an unattended run (dcn-2610222030477927) covers abcd's own launches only.
dcn-26102307575562832026-10-23 — The product thinker's walk and sign-off of itd-2610170634394993 on 2026-10-23 (about 09:50 BST, in abcd-ae's session), restated. The shared model budget is per computer: sessions on one computer share one pool, and a session on another computer or account draws on that computer's own pool, which narrows the draft's scope condition that the budget spans every account of an organisation. The ten person-visible stories are kept, the budget story in its per-computer form. The eight-hour key of a cloud run is kept: asked why eight, the product thinker was told that GitHub sets eight hours for an app's user access token and that its renewal stays on the person's computer, and kept it. The technical list is accepted in full. The press release, the mechanism and its grounds, the scope conditions and the reason for doing it now are signed off as written. Choice 1 had been ruled earlier (dcn-2610230710469123). The intent is planned on this sign-off.
dcn-26102719260705232026-10-27 — Ruling by the product thinker on 2026-10-27, relayed by the coordinating session abcd-f5 and restated: the 23 Oct plans for the coordination intent itd-2610170634394993 and the terminal-drain intent itd-2610222215485265 land now, together with the checklist intent itd-2610170638184486 and its built steps 1 to 3 (spc-2610230805429429). This settles the overlap with the 24 Oct note in #1130 that the autonomy grant itd-2610240850336695, the checklist and the coordination intent are planned together as one bundle: that joint planning still happens, and it builds on what lands here rather than re-planning it. The rebase keeps every addition #1130 and the 25 Oct edits made to the three drafts.
itd-2610180912189125A session left to work on never stops while it has work
itd-2610240850336695The person grants their sessions what they may do alone, until a time
itd-2610261025516272Private repos land checked work without renting CI