Dogfood case study
How we run an agent work queue, with the imperfect receipts included
Post 102 on our public board exposed a missing queue control. The board owner chose the work, an agent built it on a branch, tests and evidence traveled with it, and a human kept the merge and public status decisions.
Field guide
FeatureJet
Published and verified July 29, 2026
The receipt
Post 102: Expose queue ranking through the MCP server
This was not a customer success story and it did not win a popularity contest. It was a dogfood defect found while we tried to operate our own queue through MCP.
- 1
The request and its signal
Public request 102 was filed on July 22, 2026 with 0 votes. Its body names the concrete gap: owners could setqueue_rankthrough the dashboard or REST API, but not through the MCPupdate_posttool. - 2
A human made the planning decision
Votes were an input, not an autopilot. The board owner chose this dogfood defect for the next work packet, and the product ledger recorded it as must-have requirement REQ-PROD-004. An agent did not promote an unplanned public post into work by itself. - 3
The queue handed off a bounded job
Work ran on branchcodex/queue-rank-mcp. The current public post proves the request and resulting evidence, but it does not preserve expired claim history: FeatureJet exposes a live claim, then releases or expires it. We can prove this item was queued; we cannot honestly show a historical claim receipt for it. - 4
Implementation and tests stayed attached
Commit dc14b5c added set, clear, and omit semantics for queue rank while keeping propose-scoped keys unable to rank. The validation packet covered focused MCP proxy/server tests, API scope tests, and both official SDK contracts. - 5
Review, merge, and status stayed human-controlled
The handoff marked the build ready for review and held integration for the overseer. Merge commit 0b57942 landed afterward. The operations record says evidence was attached, status was proposed, and the board owner confirmed it. The review transcript itself is not public, so we do not present one as a receipt. The human kept the status and merge decisions. - 6
The public record closed
The live post is Shipped and displays the merge evidence. It still has 0 votes, so there is no honest voter-notification receipt to show for this request. On a request with verified, opted-in voters, a confirmed notifying status queues the emails; a pending proposal does not.
Two systems, two jobs
FeatureJet is the queue. Your runner does the coding.
FeatureJet owns the hand-off
The board holds public demand, the owner’s planned order, the current claim, implementation evidence, and the pending or final status. It does not open a repository, run tests, or merge code.
The customer-owned runner owns execution
Your coding agent runs in infrastructure you control with the repository permissions you choose. The nightly recipe is one example runner; FeatureJet never receives those repository credentials.
The safety boundary
Feedback informs work. It does not become authority.
A public board contains untrusted data by design. Anyone who can submit a request can write text an agent may later read.
Public text is context, not an executable instruction
The safe queue fetch passes a bounded descriptor for selection. The runner must treat the full request and comments as untrusted product context, never as permission to change repositories, credentials, billing, or deployment policy.
The scope decides what the agent may change
A propose-scoped key can queue, claim, attach evidence, and propose a status while leaving the public board unchanged until confirmation. A write-scoped key is a broader grant and can apply a status directly.
Human review is a product decision, not a decorative step
The owner decides what becomes Planned, whether the implementation is acceptable, whether code merges, and whether a public status claim is true. Automation can prepare each decision without inheriting it.