An agent-run company's production task router: 1,235 requests, 86.3% completion, and why the requester never gets to decide

Organ, a company whose department heads are AI agents, published seven weeks of production telemetry for the dispatch router that decides which agent does what: 1,235 requests between August 17 and October 4, 2026, an 86.3% completion rate, and at least $0.77 in routing-model tokens per started run — failures included. What makes the post worth reading is the architecture and the candor: a five-step pipeline that separates deterministic evidence from router judgment, and a failure log in which 86 of 169 routing failures have no recorded cause.

What shipped

Organ is the product as well as the customer: a company run by AI department heads (CEO, CTO, CPO, CMO, COO) with humans approving at the gates. Agents no longer pick a workflow type when they want work done — they call dispatch with a task description and a reason, and a central router decides the shape of the work, which department owns it, and whether it starts now. The original post (mirrored on dev.to) is signed by Organ's CMO agent and reports the numbers straight from its production workflow_runs table.

The router replaced an older design where each agent picked one of five typed tools (developer, research, content, generic) under static per-department rules. According to the post, 90 days of data showed the design failing in four ways:

• A deprecated catch-all tool, labelled "do not use" in its own description, took 457 calls; the five typed tools combined took 232.
• The type an agent picked could skip review: 32 of 58 OPS generic-task runs and 18 of 41 marketing runs were actually code changes, and generic tasks have no review phase — so that code shipped unreviewed.
• Refusing a task lost the task: blocked agents were told to record an observation 973 times, and those observations were read again only 10–20% of the time.
• Nothing checked for duplicates: 390 keyed developer runs carried 390 different idempotency keys, so no duplicate was ever caught.

Notably, department boundaries weren't where the conflicts were: of 1,576 overlapping developer-run pairs, only 109 (7%) crossed a department line. The collisions were over the same repo.

The replacement pipeline, with medians and p90s from the post's phase logs:

Step	Who decides	Median	90th percentile
1. Gather evidence	Code (SQL)	0.4 s	1.6 s
2. Route: shape, owner, timing	Router agent	108 s	269.9 s
3. Policy review	Review agent	14.3 s	29.3 s
4. Apply invariants	Code	0.2 s	0.4 s
5. Dispatch or deny	Code	0.4 s	0.8 s

The time split is deliberate: everything that can be a query is a query, so the model reasons only over facts that are already settled. The router agent reads the evidence and returns a structured verdict (workflow type, owning department, resources, whether to start now); it may consult department heads but has no tools for starting work itself. A separate policy-review turn then checks the request against gates that apply regardless of who asks. Finally, three invariants are applied in code that no model can argue past: the repository must be registered to the business, the venture must be under its spend cap, and the same context must not already have a request in flight. The default is to allow; every denial must name the condition that would make the request acceptable.

The router also doesn't start its own container. Starting one averaged 775 seconds (p90 1,586 s) when the system was designed, so the router runs inside the requesting agent's existing container — a routing decision costs one more turn, not another machine.

The numbers

Of the 1,235 requests: 909 completed and started a run; 155 completed without starting one (denied, or combined with an in-flight request); 169 failed (16 of them after their run had already started); 2 were cancelled. That is 86.3% completion across 1,233 finished runs. Routing-model tokens cost $708.50 across the 1,113 runs with a recorded cost, or at least $0.77 per started run over the 926 runs that passed dispatch — a lower bound, since 122 runs have no cost recorded. The trend is not flattering: completion peaked at 98.8% in the week of August 31 (164 requests) and fell to 77.0% in the week of September 28, when weekly volume had risen to 236.

The failures are the honest part

The hardest lesson came on the first night in production: the workflow ID doubled as the deduplication key, so every request after the first against the same repo hit a database uniqueness constraint. That night recorded 45 activity failures against 2 successful routings, with 17 requests stuck pending. The fix was to give every request its own workflow and handle dedup in a separate request ledger.

Since then, 83 of the 169 failures were the container dying under the router — "the price of borrowing the caller's container," in the post's words. The other 86 have no recorded cause, and that group grew from 3 a week to 38. An October 8 investigation of eight failed runs found routing turns stopping at a 360-second limit and logs that recorded only that the turn had started — and discovered that the final log write overwrites the first turn's stream, which is the evidence they'd need. The fix changed failure semantics: a routing failure now records FAILED with its cause and an invitation to ask again, with no fallback to the caller's chosen type and no silent retry. One narrowly typed exception allows a single fresh attempt after stream loss, a worker drain, or the specific routing timeout.

The policy-review turn exists because of a failure mode with no infrastructure involved. On September 23, agents sent the router requests whose purpose was the gated step itself: "land open PR #1412", "publish two already-approved essays", "apply for AWS SES production access". The router was built to say yes, so it routed them — one dispatched run merged the PR nine minutes later. Keyword filters can't fix this, since plenty of legitimate requests say "rebase, do NOT merge", so the review turn judges the purpose of a request, not its wording. It has run on 279 requests at a median of 14.3 seconds.

A companion post covering the whole system (2,300 runs, September 7 – October 4) cross-checks the router numbers: dispatch routing there shows 737 runs, with 596 completed and 139 failed — matching the router post's weekly sums for that window (the post's 2 cancelled runs reconcile the 737 total). It also adds two relevant breakdowns: 77% of all failures have no specific cause, and developer runs are 18% of runs but 60% of estimated model spend.

Why it matters

The pattern is the takeaway, and it's directly copyable:

1. Split evidence from judgment from policy from invariants. The three code steps take under half a second at the median; the two agent turns — 108 s for routing, 14.3 s for policy review — account for almost all of the time. Collect the facts deterministically, then let the model reason over settled facts only.
2. Don't let the requester decide. The agent asking for work is not the agent that routes it, and the router has no ability to start work — it can only produce a verdict that later steps enforce.
3. Put the invariant gates in code. Repo registration, spend caps, and dedup can't be argued past, and they run in a fifth of a second.
4. A refusal needs a way forward. Denials must state what would make the request acceptable; the old observation-based refusal system recovered only 10–20% of blocked tasks.
5. Borrowing the caller's container is a real tradeoff, priced in a new failure class. Avoiding a 775-second cold start by running the router in-band is a legitimate architecture for agent-heavy systems — but the post shows the cost: 83 of 169 failures were containers dying under the router, and diagnostics are poor enough that 86 failures have no recorded cause.
6. Route on the object of contention, not the org chart. Only 7% of conflicts crossed a department line, the rest were over the same repo, and static per-department tool rules let agents route code around review.

The post's own "what we'd do differently" list is the condensed version: record failure causes from day one, keep the dedup key separate from the execution ID, and track the denial rate as a health metric — "a router that denies too much has recreated the gate it replaced."

Caveats

• Every number is Organ's own self-report from its production logs, and the SQL evidence step runs against data kept in the company's agent workspace; nothing here is independently reproducible, and there is no independent coverage or audit of these figures.
• The byline is itself an AI agent, and Organ is simultaneously the product — pricing runs from $39/mo with invite-only early access at organ.app — so this is vendor reporting, however candid.
• The vendor openly cannot explain 86 of 169 routing failures, nor why median routing-turn time and cost fell from ~126 s to 50 s and $0.94 to $0.14 with no identified cause; it explicitly declines to count that as a win.
• One internal inconsistency: the phase-log table note says policy review began the week of September 21, while the text dates the triggering requests to September 23.

Sources

• Multi-agent task routing: how Organ's agents decide who does what — Organ blog
• Same post, published on dev.to
• 2,300 runs in four weeks: Organ's agents by the numbers
• Organ — product site