Consolidating the Tunnels: A Unified, Governed, Cost-Capped Agent Work Bus

1. The Problem: One Primitive, Eight Implementations

A production ANO accumulates pipelines the way a growing company accumulates

departments. Ours arrived independently, over months, each solving a real and immediate

need:

- a PRD pipeline that moved requirements through an eight-stage state machine on a

sixty-second poll, with its own state and log tables;

- a discovery-to-PRD path that scored incoming intelligence and promoted the worthy

items, with its own capped triage timers;

- a support-ticket loop that assigned tickets to agents;

- a work-loop that drove dozens of per-agent timers scanning for things to do;

- and a family of research / grant / water-quality tunnels, each with its own runner

and schedule.

Examined together, every one of these is the same four-beat primitive:

**event or state-change → classify and route → an agent acts → the result advances

state, triggers the next step, or replies.**

That primitive is the messaging system. But because each pipeline implemented it

privately, the organization paid for it eight times and inherited three structural

pathologies.

shared ceiling, no shared throttle, and no shared view of what inference was being

purchased and why. The work-loop alone — dozens of agents each waking on a timer to

speculatively look for work — emitted thousands of low-value messages in a single month.

A speculative scanning loop with no governing cap is a firehose pointed at a metered

API. The roughly four-thousand-dollar month was not an exotic failure; it was the

predictable result of N ungoverned surfaces, any one of which could spiral.

a stuck unit of work. We later found messages that had been claimed by an executor that

then died — and then sat, mid-flight, for as long as forty-nine days. Fourteen of them

were real human-initiated requests. The expiry mechanism only reclaimed work that had

never started; it had no concept of work that had started and stalled. Fragmentation

hid the failure mode.

doing right now, what has failed, and what is it costing?" The information existed, but

only as eight separate, differently-shaped puddles.

The fragmentation thesis is well understood in distributed systems: duplicated

infrastructure multiplies not just maintenance but risk surface. In an ANO, where the

infrastructure spends money autonomously, that risk surface is denominated in dollars

and in trust.

2. The Design Decision: Consolidate on What You Already Run

The instinct when consolidating message-passing is to reach for dedicated infrastructure

— a broker such as Kafka, a queue such as SQS, a workflow engine such as Temporal. These

are excellent tools. They were also the wrong tool for us, and the reasoning is

instructive because it generalizes.

We already ran PostgreSQL. Postgres offers, natively and transactionally, every

primitive a dispatch bus requires: triggers to fire on state changes, `LISTEN`/`NOTIFY`

for sub-second wake-ups, partial unique indexes for deduplication, row-level locking for

atomic claims, and ordinary SQL for routing and stage advancement. Adopting a separate

broker would have added an operational dependency, a second source of truth, and a new

failure mode — to buy capabilities we already possessed.

So the direction we chose was a Postgres-native bus: one envelope table

(`agent_messages`) carrying every unit of agent work, advanced by database triggers and

consumed by a thin, shared stage-runner. A cockpit may read this bus, but it is never the

source of truth. The domain logic of each pipeline stays where it belongs — as the

This is a deliberately conservative architecture, and the conservatism is the point. The

correct exit condition is explicit: should message volume ever approach the limits of a

single Postgres instance — a regime perhaps two orders of magnitude beyond our current

load — the transport can be swapped behind the same envelope contract without rewriting

the pipelines. We are designing for the scale we have plus comfortable headroom, not for

a hypothetical scale we may never reach. Building for imaginary scale is its own form of

waste.

3. The Architecture

The bus is defined by an envelope, a contract, an event-driven dispatch path, and four

governance layers. None of the individual mechanisms is exotic. Their combination —

and the fact that they are shared across every pipeline — is the contribution.

3.1 The Envelope

Every unit of agent work, regardless of which pipeline produced it, is a row in one

table. The envelope carries the directive and context, the originating and target agents,

a status, a lane, and an idempotency key. By unifying the envelope — and only the

envelope, not the domain state — every pipeline immediately inherits lanes, deduplication,

tenant scoping, and a single observability surface, without surrendering its own logic.

3.2 Priority Lanes

Work is classified into three lanes: interactive (customer- and human-facing, never

starved), batch (backfills and bulk triage, which must never block interactive work),

and system (housekeeping and monitors). The classification is deterministic and

defaults to interactive — the safest default, because the failure mode of a

misclassification is "this ran a little sooner than necessary," not "a customer waited

behind a backfill." Lanes are what let a thousand-item discovery backfill and a live

customer request share one bus without the backfill ever delaying the customer.

3.3 First-Class Idempotency

Every dispatchable unit of work carries a deterministic key derived from its source,

its source identifier, and its stage. A partial unique index makes a duplicate dispatch

a no-op at the database level. This is what makes the entire system safe to retry: a

re-fired trigger, a re-run tunnel, or a re-delivered notification cannot produce

duplicate work, because the second insert simply collides with the first and is absorbed.

Idempotency is not a feature bolted on for robustness; it is the precondition that makes

event-driven dispatch tolerable at all.

3.4 Event-Driven Dispatch

The legacy model was polling: dozens of timers waking on a fixed interval to ask "is

there anything to do?" Polling has two costs — latency (work waits up to a full interval)

and waste (most polls find nothing, yet each poll is a unit of compute and, when it

triggers speculative LLM calls, a unit of spend). We replaced the poll with a database

trigger that enqueues a directive the instant a unit of work becomes ready, paired with a

`LISTEN`/`NOTIFY` wake-up so the consumer reacts in well under a second, and a long

fallback poll as a safety net. The notification is treated as a best-effort hint, never

as a guarantee; correctness rests on the durable claim query, and timeliness rests on the

notification. This is the standard, durable pattern for Postgres-backed queues, and it

eliminates the empty-poll firehose entirely: the system does work only when there is work

to do.

3.5 Model Routing Under a Hard Cap

Not all agent work requires a frontier model. Mechanical work — classification, scoring,

extraction, formatting, health checks — routes by default to a local model running on

owned hardware, at zero marginal inference cost. Genuine reasoning — synthesis, analysis,

drafting, evaluation — routes to a cloud model. The routing never downgrades reasoning

to save money; quality-critical work is never silently sent to a weaker model. Above this

routing sits a hard monthly spend cap enforced at the bus itself. The cap is the

structural answer to the four-thousand-dollar month: with a single governed dispatch

surface, there is exactly one place to enforce the ceiling, and a runaway loop becomes

impossible rather than merely unlikely.

3.6 Self-Documenting Change Broadcasts

An ANO's agents operate from a standing contract and a memory layer. When the operating

model changes — when dispatch becomes event-driven, or a routing policy shifts — the

agents must learn of it, or they will continue to act on the old assumptions. Editing

each agent individually does not scale and is error-prone. Instead, an operating-change

is published once, as a time-boxed, scope-filtered notice that the memory layer injects

into every relevant agent's context on its next run. The cutover primitive that flips a

runtime flag also publishes the corresponding notice in the same step, so every change to

the operating model is self-documenting to the workforce. A silent change to how the

organization runs is treated as a defect, not a convenience.

3.7 One Observability Surface

Because every pipeline shares the envelope, a single cockpit answers the questions that

eight separate puddles could not: the current queue by lane, throughput and failures over

time, the health of event-driven dispatch, deduplication activity, the unified transition

log, active operating-change broadcasts, and the day's spend. The cockpit reads the bus;

it never governs it. Observability that is a side effect of the architecture, rather than

a separate system to maintain, is observability that stays accurate.

4. Why It Is Efficient

Efficiency here is not a micro-optimization claim; it is a structural one.

messages per month — a load a single Postgres instance handles without noticing. The real

constraint on throughput is LLM concurrency, which is cost-bound, not queue-bound.

Spending engineering effort to make the transport faster would optimize the wrong

variable. The bus is designed to be boring precisely so that effort can go where the

constraint actually is.

function of time — every interval, forever, whether or not there was work. The

event-driven model spends as a function of events — only when real work exists. This

inverts the cost curve from "always on" to "on demand," and the hard cap bounds the worst

case regardless.

shared substrate retires operational surface rather than adding it. There is no new broker

to run, patch, and monitor. The one-time migration cost is real; the recurring cost is

lower than what it replaced.

ungoverned cost-and-risk surfaces collapse to one governed surface. The

four-thousand-dollar month was one ungoverned tunnel. After consolidation there is a

single place to cap spend, a single place to see failures, and a single place to reclaim

stalled work — which is how, in the course of this consolidation, a forty-nine-day

backlog of silently-lost work was found and cleared, and the gap that allowed it was

closed permanently.

5. How It Scales

Scaling concerns fall into three categories, and the design has a deliberate answer for

each.

fast as it grows; query timeouts on the hot table are treated as the canary that triggers

archival. Lanes and per-tenant fairness ensure that growth in one class of work — a large

backfill, a busy customer — cannot starve another.

organization and every provisioned ANO without cross-contamination, because isolation is a

property of the envelope, not of a per-tenant deployment.

particular hosted vendor, it runs unchanged on a local database. A sovereign deployment —

an appliance that performs all inference and stores all data locally, with no external

egress — can run the identical design against a local Postgres or a self-hosted instance

of the same managed stack, with no change to the pipelines. The architecture that governs

the cloud organization is the same architecture that can run, fully offline, on a single

machine. Sovereignty is not a separate product built on a different substrate; it is the

same substrate, relocated.

The exit ceiling remains explicit: if volume ever truly demands it, the transport can be

replaced behind the envelope contract. That option exists, costs nothing to preserve, and

is — by deliberate design — far from being needed.

6. Limitations and Honest Caveats

This is a position paper describing an operating architecture, not a controlled

experiment, and it should be read as such.

- The cost figures are operational observations from our own environment, not a

benchmark. The claim is directional — fragmentation produced runaway spend; consolidation

bounded it — not a precise measurement under controlled conditions.

- The consolidation is staged and reversible. Several pipelines run their new behavior

behind flags that default off; the migration is deliberately incremental, and not every

pipeline has completed its cutover. We describe the architecture and the path, and we are

explicit that some cutovers remain gated.

- `LISTEN`/`NOTIFY` is a best-effort transport. The design depends on this and treats the

durable claim query — not the notification — as the source of correctness. A reader

building on this pattern who treats the notification as a guarantee will eventually lose

a message.

- The deepest layer — codified self-governance, in which the system itself decides which

work is autonomous, which requires an approval, and which must escalate to a human — is

the destination, not yet the present state. The substrate described here is built to feed

that layer; the layer itself is future work.

7. Conclusion

The lesson of consolidating eight pipelines into one bus is not "use a queue." It is that

in an organization where software spends money and makes decisions autonomously, the

change, and one honest observability surface — is the part that makes autonomy safe,

affordable, and trustworthy. The queue is the easy part; every adequate database provides

one. The governance is the part most organizations will skip, and skipping it is precisely

how a four-thousand-dollar month, a forty-nine-day silent backlog, and an opaque agent

workforce happen.

We built the boring substrate on the database we already ran, put the governance where the

work flows, and made every change to the operating model announce itself to the workforce

that has to live by it. That is the foundation on which an organization can credibly aim to

run itself — with humans steering policy from above the system rather than approving work

inside it.

References

[1] MSR Research. Unified Agent Work Bus. PRD `2026-05-30-1044`. Internal.

[2] MSR Research. Resume Claude Code — Cost Controls & Event-Driven Dispatch. PRD `2026-05-29-1218`. Internal.

[3] MSR Research. Agent Work Bus — Reusable Substrate Packaging + Sovereign Backend. PRD `2026-05-31-2000`. Internal.

[4] MSR Research. Architecture: Agent Messaging & Memory Layer. `ARCHITECTURE.md`, `architecture/agent-work-bus.md`. Internal.