The Agent Interface measured what contributors write into an agentic system. The Dispatch Layer opened the routing architecture that determines what happens to those contributions. This essay asks what a better routing architecture looks like.
Not in the abstract. Against the specific failure modes those two essays documented — in one repository, with open-source workflow files, against real issue timelines. The recommendations that follow are scoped to what the evidence supports.
The ratio assumption
gh-aw’s routing architecture is rational. It processes thousands of issues with minimal human involvement. The eligibility gate protects the dispatch queue from spam. The priority scoring is transparent and deterministic. The moderation layer screens for abuse.
The architecture was designed for a repository where 86.5% of issues are bot-generated. In that world, the routing makes sense: bot issues are trusted by construction and enter the queue automatically. Community issues are rare enough that one maintainer can manually promote them. The moderation layer is a security measure, not a bottleneck.
But that ratio is a snapshot, not a law. As more contributors write into agentic systems — the thesis of The New OSS — the assumptions embedded in the routing change. Five things break.
1. Silent failure on moderation errors
In The Dispatch Layer, three AI Moderator runs crashed on community issues filed March 8, 2026. The moderator’s Codex agent failed at execution. No ai-inspected label was applied. The eligibility gate stayed closed. The issues sat invisible to the dispatch system for six hours until a maintainer manually intervened.
The contributor received no notification. No error message. No indication that their issue was sitting in a dead zone between moderation and dispatch.
The system fails closed on moderation errors. A crashed moderator has the same downstream effect as a positive spam detection. That is the correct default for a security layer — but it is the wrong default for a routing layer. Security should fail closed. Routing should fail visible.
The contributor has no signal that their issue is stuck. The maintainer has no signal that the moderator crashed on valid input. The issue waits until someone notices.
A crashed moderator should produce a visible artifact: a label, a comment, or an entry in a review queue. The contributor should know their issue is pending review, not silently blocked.
The fix is not to remove moderation. It is to separate the moderation failure path from the eligibility failure path. A moderator crash is an infrastructure error, not a content decision. It should be routed to the maintainer as a review item, not silently absorbed.
2. Conflated moderation and quality assessment
The AI Moderator’s prompt asks a single agent to answer two different questions: “Is this content spam or abuse?” and “Does this content look AI-generated?” Those questions have opposite implications for dispatch quality.
The heuristics for AI-generated detection include em-dashes in casual contexts, perfect grammar, and “perfectly structured responses that lack natural conversational flow.” These are the same qualities that produce high-signal issue reports — the kind that, in The Agent Interface’s data, correlated with faster resolution.
The moderator treats polished writing as a risk signal. The dispatch system treats diagnostic evidence as a speed signal. The same issue that would resolve fastest once dispatched faces the most friction getting dispatched.
The moderator decides both whether content is safe and whether content is trustworthy. A polished, well-structured bug report can trigger AI-generated suspicion.
Safety moderation should catch spam, abuse, and malicious content. Quality assessment should measure signal density, specificity of intent, and diagnostic evidence. They are different questions with different failure modes.
This does not mean removing AI-generated detection. It means not letting it gate dispatch eligibility. An AI-assisted issue with perfect diagnostic evidence should route faster, not slower — regardless of how it was written.
3. Documented behavior that diverges from reachable behavior
This is not a single gap. It is a pattern across three workflows.
Cookie promotion. q.md line 296 describes a guard rule: “Do not add the cookie label to an issue unless the ai-inspected label is already present.” This implies a promotion path from ai-inspected to cookie. But q.md’s own safe-outputs only allows adding spam — it cannot apply cookie. No other workflow in the current source implements this promotion for community issues.
Community labeling. auto-triage-issues.md instructs the agent to add the community label when author_association is NONE, FIRST_TIME_CONTRIBUTOR, FIRST_TIMER, or CONTRIBUTOR. But the compiled workflow gates activation on write-level collaborator permission — admin, maintainer, or write. The check_membership.cjs helper checks context.actor’s repo permission, not author_association. Read-only community contributors — the people the prompt describes — never reach the agent.
The write-level gate may be an intentional security decision. gh-aw’s security posture is cautious about untrusted inputs, and in one activated run an integrity policy blocked even reading the issue content. But whether the gate is intentional or not, the effect is the same: the documented behavior and the reachable behavior diverge. The workflow runs green while doing nothing for ordinary community reporters.
In the March 2026 runs checked: the auto-triage workflow triggered on issue #22380 filed by samuelkahessay — the pre-activation step found repo permission read, and all subsequent jobs were skipped. Another contributor hit the same gate on #22469. The only run that activated was filed by an author with admin permissions — and even that run failed because an integrity policy blocked the issue read.
Moderation. ai-moderator.md adds ai-inspected when content passes review. But its failure path — a crashed agent, a timeout, an infrastructure error — produces no label, no notification, and no retry. The success path feeds the eligibility chain. The failure path silently breaks it.
Whether the gate is intentional or a configuration issue, the prompt describes a path that read-only community contributors cannot reach. Community labels in the sampled data were added manually by pelikhan.
The guard rule describes a promotion contract with no implementation. Cookie promotion exists only as a constraint, not as a capability in any workflow.
The moderator's success path works. Its failure path silently blocks the entire downstream chain. No retry, no fallback, no contributor visibility.
In all five community issues carrying the cookie label as of March 24, 2026, the labels were applied manually by the same maintainer.
The fix is structural: audit compiled workflows against their prompt-level intent. If a prompt says “add this label for external contributors,” either the activation gate should permit those contributors, or the prompt should document the actual scope. If a guard rule describes a promotion path, a workflow should implement it. If a moderation agent can fail, its failure should produce a visible artifact.
The gap between what the prompts describe and what the compiled workflows deliver is the gap between the architecture’s intent and its behavior. Closing it does not require changing the security model — it requires making the security model’s constraints visible in the documentation and building the community paths that work within those constraints.
The Agent Interface’s data suggests the threshold for automated promotion does not need to be complex. Issues with error output and a file path resolve at a median of 0.47 days in bugs. A simple signal-density check — does the issue carry at least two diagnostic signals? — would capture the majority of actionable reports.
4. Trust by provenance, not properties
The deepest architectural assumption is that trust is a function of who filed the issue, not what the issue contains.
A bot-generated issue with a one-line title and no diagnostic evidence enters the dispatch queue instantly — it was created by a trusted workflow and stamped with cookie at creation. A community issue with error output, file paths, line numbers, proposed code, reproduction steps, and fix language sits outside the queue until a human decides it belongs there.
The system does not evaluate issue quality for eligibility. It evaluates authorship class.
Bot-generated issues skip moderation and enter dispatch immediately. Community issues face moderation, require ai-inspected, and require manual cookie promotion. The same issue body would route differently depending on the author.
Eligibility should be a function of issue properties: signal density, specificity of intent, diagnostic evidence, and body structure. Author class can adjust priority weighting or review requirements, but should not be the eligibility gate.
This does not mean trusting all community issues blindly. It means building an evaluation layer that reads the issue body the way the implementation agent will read it — and making eligibility decisions based on what it finds. The triage agent already reads title and body to assign labels. Extending that to a quality score is the same operation with a different output.
5. The scaling constraint
The manual promotion gate works. At the current scale — 435 community issues from 158 contributors in the analyzed window — one maintainer can review and promote issues manually. pelikhan does this, and the issues get resolved.
The question is not whether the current architecture is broken. It is whether it scales.
Five out of 435 community issues received the cookie label. That is a 1.1% promotion rate. The other 98.9% were resolved through other paths — maintainer direct action, contributor workarounds, or waiting.
If the community contribution rate doubles — which is the direction The New OSS argues — the manual gate becomes the system’s constraint. Not because the maintainer is slow, but because the architecture concentrates a routing decision in a single human. The dispatch infrastructure can process three issues every 30 minutes. The bottleneck is not throughput. It is admission.
What these have in common
The five failure modes share a root cause: the routing architecture treats community contributions as an exception to handle, not a workload to optimize. Bot-generated issues are the primary flow. The infrastructure — moderation, eligibility, promotion — exists to manage the secondary flow.
That is a reasonable design for a repository where community issues are 5.7% of volume. It becomes less reasonable as that percentage grows. The architecture does not need to be replaced. It needs to be extended:
- Moderation errors should produce visible artifacts, not silent blocks.
- Content safety and dispatch readiness should be separate evaluations.
- The promotion path described in policy should exist in implementation.
- Eligibility should respond to issue properties, not just author class.
- The admission decision should not concentrate in a single human.
None of these changes require abandoning the current architecture. They require building the community path to the same level of automation as the bot path. The infrastructure already exists — scoring, assignment, implementation, review. The gap is in how community issues reach it.
The routing architecture is open source. The contribution data is open source. The failure modes are documented in The Dispatch Layer and The Agent Interface. What remains is the engineering.