GitHub work queue comparison
Decision (2026-10-09): cgwalters chose option (b): continue agent-board toward a “somewhat hardened functional PoC”, with agentic-job the more important primitive. Keep watching gh-aw and share ideas and code with it and other projects where useful. “Ideas not code” below means not adopting the native scheduler now, not a prohibition on code reuse.
The decisive difference is authority: gh-aw's native queue makes a Git ledger authoritative and Issues a projection; agent-board keeps the operator-edited board as the work-intent record. Adopting the queue would change that decision, not just remove duplicate code. This comparison is a snapshot of gh-aw a7fd806c98b135659c106b58e582f768987c95b0, agent-board 179f6001b50da494ae547c2fbbad39f6c09566b4 and agentic-job ebca2031f624eab2f9e44b8d131f72411f67b5da, not a statement about their latest versions. Board purpose and durable model provide the baseline.
What gh-aw supplies
Native version 3 is Git-only: work-queue.jsonl, normally on branch work-queue, is a causal transaction log and the only queue authority. Issues/PRs can be dependency nodes, not storage. Trusted operator/runtime writers must be allowed on the protected branch; no force-update/deletion and no queue credential in agent execution. Policy installation does not install or verify those protections. Queue storage, deployment prerequisites.
Work is an immutable task/DAG node; Claim authorizes one scheduler-selected attempt; Policy is administrator-installed scheduling, producer, routing and limits configuration; Pool groups worker routes/capacity; Reservation holds capacity through uncertain launch/termination; Completion durably records finishing before effects; Result follows independent verification of delivered effects, not job success. Default selection is FIFO within a shared accounting key; weighted fairness charges durable Claims, not CPU or successful results. Lifecycle definitions.
The dispatcher stages intents; trusted processing commits assignments/reservations, authenticates the launch credential, persists a start fence, dispatches the Policy-pinned workflow SHA and binds the actual run. Activation authenticates workflow/revision/run/attempt: assignment JSON alone is insufficient. Outputs belong to an original Claim. Completion precedes effect authorization/delivery, Result follows native readback. Ambiguous launch retains capacity; uncertain delivered effects are not replayed. Dispatch and effects.
Backing Issues are mirrors, not intake. Existing Issues require exact installed projector grants, not just a label. Human title/body/discussion/unrelated fields are preserved. Closing an Issue or editing its status does not establish queue cancellation or Result. Completion projects to Verifying; verified PR delivery to Needs review; non-PR Result to Done. Default is keep-open; close-on-result must be authorized before admission and only applies to verified non-PR delivery. Issue projection.
status-field is a pre-provisioned organization single-select Issue field, not Projects v2 Status. Its nine options are Queued, Blocked, Assigned, Running, Verifying, Needs review, Done, Needs attention and Cancelled. Comment-only projection needs no field or Project. Native queue integration with our board is not established; it needs an adapter. There is no Issue intake scan/global repair sweeper: subsequent authorized hooks owning the same Work/Claims retry projection. Ambiguous unreceipted creation can remain pending indefinitely; automatic fence-clearing crash recovery is not implemented. Projection limits.
WorkQueueOps is a separate lightweight pattern: issue checklists or sub-issues read through GitHub tools, safe outputs marking progress and a shared Actions concurrency group. Checklists are suggested for fewer than 100 items; sub-issues preserve separate discussion/assignee/status. Neither supplies native fairness, verified dependencies or Claim authority; concurrency does not protect against humans/other workflows. Cache/repo-memory alternatives do not fit our no-second-store choice. WorkQueueOps.
Maturity and integration limits
The native machinery is recent: operator implementation, Oct 2, runtime store, Oct 2, fair-DAG/Claim-effects replacement, Oct 8, backing-Issue mirrors, Oct 8 and checkpoints/maintenance, Oct 9. The lightweight pattern, Apr 8 predates it. These dates came from the research's fetched Git history.
The replacement changeset describes breaking incompatibilities with the experimental protocol and no migration. Current CLI help does not call itself experimental, but that does not establish maturity. Release v0.91.6 (Oct 8) describes mandatory fair DAG queues with Claim-scoped effects; the pinned CHANGELOG stops at Feb 3 and does not substantiate these changes.
The implementation coverage table reports Go/JS scheduling, Claim-scoped output paths, compiler/operator integration and examples implemented. Writer-restriction automation is deferred, automatic workflow bootstrap unsupported, hosted immutable-SHA dispatch/run-details compatibility unverified, live intended-token Issue/field writes unclaimed, full runtime/host refinement unproved and live Git/API contention unverified. Formal models are bounded evidence, not a deployment-security certificate.
Checked-in examples include an ESLint Factory and a daily dispatcher with ten report workers (three admitted daily). Factory tasks are independent roots, not an automatic miner→refiner→monster chain. Successful provisioned live use is not established: Daily Portfolio calls itself an orchestration example; its dispatcher source and coverage limits are not hosted-run evidence.
The queue is not limited to a model engine, but is not a drop-in scheduler. The Go operator CLI can read/install/submit/grant/reconcile independently; dispatch-next commits assignments but does not POST a launch. Go has a protected embedding-host entrypoint; JS exposes dispatcher functions with trusted callbacks. Full launch/activation/Claim-scoped effect hooks are wired for compiled gh-aw workflows. An ordinary-workflow or agentic-job end-to-end adapter with our sandbox is not established. It needs authenticated run/attempt binding, protected intent ingestion, effect authorization/readback and independent Completion/Result settlement, not merely an assignment input.
Trusted ledger writers need Contents write; dispatch needs a Policy-matching token/App principal and Actions write; worker binding/evidence needs Actions read. Backing-Issue hooks request Contents write, Issues write and Actions read, with optional separate projector App tokens. Organization field capability and protected coordination refs need checking. Effect appliers need their resource permissions; agents receive staged intents/snapshots, not writer tokens. See dispatch credentials and deployment permissions. agentic-job's existing handler pin is older: native v3 integration would be an explicit pin/contract/security change.
Side-by-side (pinned implementation versus intended design)
| Concern | gh-aw native | agent-board implementation / intended design |
|---|---|---|
| Record/authority | Git ledger; Issues projection. Source | Board for intent; issues/PRs/Actions for facts; no second live store. Design |
| Human steering | Queue admin cancel/reprioritize through checked ledger transactions; Issue edits cannot cancel/finish Work. Source | UI-edited Agent assignment is trusted only if all project writers may assign; operator answers/priorities/turn live on forge. Assignment decision, design |
| Reading/repairs | Replay log and scoped Issue projection; no global intake/repair scan. Source | Paginated project/schema/items reader; missing Status→Triage, Done/open→review only, known closed reason→Done/Cancelled. Wider census/repair designed. Rules, limits |
| Selection/capacity | Fair DAG scheduler, Claims, conservative reservations. Source | Argv-only dispatch preview; one-slot approval/budget admission designed, not implemented. Dispatch seam |
| Identity | Actual workflow SHA/principal/run/attempt plus original Claim scope. Source | check proposals --as checks assignment/output/field scope, not run authentication, race prevention or complete value/bounds validation. Name gate |
| Effects/results | Completion→authorized effects→independently verified Result. Source | Unapplied proposals; Run/Result URL grammar is not provenance. Separate policy→agent→check→apply machines via agentic-job; board closure/readback contract incomplete. Bounds, seam |
| Operator approval | Policy/profile and dispatch limits; per-run human board approval not established. Example | Explicit approval before each run/destructive request, finite budgets, unknown usage blocks admission. Decisions |
| Projects/asks | Issue field is not Project Status; native board/ask integration not established. Source | Projects v2 fields and operator asks central to design; ask/mutation commands not implemented. Design |
These are not equivalent security guarantees. The assignment decision chooses CI-bound names, one shared applier, UI-edited Agent assignment and protected-main policy; the pure name gate is not authenticated run authorization. agentic-job supports separately bounded project edits, but that does not complete board integration. The design's final decisions, not its older “current support” paragraph, set one slot/approval and the strict mutation classes: project edits, create/close issues and typed requests; no agent comments, assignees or sub-issue links.
Options (proposed work, not existing integrations)
(a) Native scheduler + board facade
Build board/issue→immutable Work admission, board priority/approval→authenticated ledger commands, Work/Claim/Result→board readback, exact backing-Issue grants and an agentic-job Claim-aware adapter (or compiled gh-aw workers). Keep reader/repairs/asks/identity; remove the planned homegrown selector/reservation/DAG lifecycle only after parity is proven. Depend on gh-aw CLI/compiler/runtime versions, Policy, protected ledger/coordination refs, dispatcher/hook/effect credentials and live-host gates. This serves multi-worker fairness/recovery, but adds two coordination surfaces for one approved slot and changes board authority. Board approval must not accidentally admit a different fair winner.
Stage first an isolated one-slot/no-write queue and approved singleton worker with manually installed Policy/protections, then one bounded effect with verified Result/Issue projection and canary isolation. Defer custom agentic-job integration; two smoke runs would not validate it. Lifecycle, coverage.
(b) Continue, ideas not code — chosen
Build the missing trusted one-slot approval/dispatch join, actual run+attempt/result recording, identity gate in check, fresh assignment check before apply and narrow readback/drift repairs, one seam at a time. Do not front-load the deferred general inventory/accounting system. Keep existing board tooling; defer multi-worker fairness, batching and general dependency/DAG scheduling from near-term scope. Borrow Claim vs launch, Completion vs delivered result, uncertainty holding capacity, immutable run identity and no blind replay. Depend on existing agentic-job/broker/Actions/Projects and already reused gh-aw safe-output handlers, not a second queue protocol. This fits one operator approving a few agents while retaining the board as record.
Stage an operator-approved scripted item with refused unassigned/peer targets, then one real approved item with trusted run/result recording, readback and duplicate/ambiguous-dispatch refusal. This tests the missing seam, not a general scheduler. Board seam, handler reuse, dispatch contract, scope decision.
(c) WorkQueueOps only, no native queue
Use existing issues (prefer human-created sub-issues over agent checklist rewriting), one approved item/run, shared concurrency and separately bounded close/project-update outputs with receipts. Build parent pagination/progress views and retry/result checks only as needed; defer native Claims/Pool/Policy/ledger and fair scheduling. Depend on GitHub issues/relationships, Actions and our checker/applier, not native queue tooling or gh-aw engines. It fits a small visible backlog, but does not replace board identity/asks/repairs or solve dispatch authorization. Do not enable the example's agent update-issue/comments/sub-issue mutations under our strict profile.
Stage a human-created parent and two staging children with one approved scripted child, then bounded closure/project readback plus repeat-run refusal while the second child/canary stays untouched. Pattern, board authority, output bounds.
Option (b) can use (c)'s human-created issue organization where useful. Revisit (a) only when concurrent workers/dependency scheduling justify changing the record of authority. No live writes, workflows, builds or tests were run for the original research.