Part of one argument: agents propose, a human decides, the record survives.
Agent org design

The specification is the system

A written operating standard for deploying AI agents: one job per seat, a published evidence base behind every recommendation, an audition before anything is trusted, and a human holding every decision. Designed against the research on why these systems actually fail.

Read the full specification

Specialist seats under one human decision gateSpecialist seats sit under a single decision gate; recommendations rise to the owner, who decides and signs, and every ruling is logged.OwnerDecision gateOps and SCAnalyticalseatsAdvisory seats
Specialist seats sit under a single decision gate; recommendations rise to the owner, who decides and signs, and every ruling is logged.
42%of multi-agent failures trace to specification, not the model
Why it matters

Eleven seats specified, three written to audition standard. Building the rest earlier would be theater. Most multi-agent systems fail on specification, not model quality, so I write the governance first and let the org chart follow. A specification, not a running fleet.

SPECIFIED

Problem

Organizations deploying AI agents assume the risk is model quality. The research says otherwise. Across more than 1,600 execution traces from seven multi-agent frameworks, roughly 42% of failures traced to specification and system design: vague roles, undefined completion criteria, unchecked authority. Not a model problem. A management problem, and one that better models will not fix.

The implication for anyone deploying this in an operating company: the design document is the control. So I wrote mine, publicly, before building.

What it does

The design is a standard, not a running fleet, and its worked example is the seat that maps to the job I want: planning and inventory. That seat has one job. Every planning, inventory, or MRP analysis selects the best published statistical model for the observed demand pattern, cites it, recalculates, and states its limits. Never a naive average.

Evidence base: demand classified by ADI and CV squared decides the model. Croston's method for intermittent items, the Syntetos-Boylan approximation correcting its bias, TSB where obsolescence risk matters, and the M5 findings on tree-based methods at higher aggregation levels. DDMRP policy bands translate the output into a decision.

Audition: fed a dataset with known answers, it must classify the SKUs, pick per-class models with citations, and flag the series where a simple average would have been badly wrong. If it misses that series, it is not used. That is the difference between an AI that produces a forecast and one that produces a forecast someone can defend in a planning review.

Eleven seats are specified. Three are written to audition standard. The rest ship only when the inputs exist to make them real, and some may never ship at all. A seat that cannot pass its audition does not get hired, same as a person.

Outcomes - every claim graded

Every claim here is either verified against an artifact I can show you, or marked as my own report. Ask for either.

  • Every seat maps to a documented, published framework, and every cited source opens live
  • Ships as a self-contained static page, no external calls, rendered clean under production CSP
  • A specification, not a running fleet. Nothing is deployed and each seat ships only after passing a written audition

Governance

  • Recommend, never decide: rulings land in a decision log and a named human signs
  • Grounding for facts, judgment for framing: analytical seats search, cite, and recalculate, and no seat invents a number
  • No claim ships beyond what the record supports; a missing fact is escalated, not guessed
  • Audition before trust: no seat is used until it passes a written test against cases with known answers
  • One job per seat, with a written definition of done
  • Strict separation: no confidential material from any outside obligation enters a knowledge pack

What transfers

I write the governance before the code, I source the reasoning to published work rather than opinion, and I mark what I have verified separately from what I am asserting. Applied here to an agent fleet. Applied at work to forecasts, supplier decisions, and planning policy, where being wrong costs inventory rather than embarrassment.

Stack

Multi-agent designOrchestrator-workers patternEvaluator-optimizer loopEvidence-based knowledge packsHuman-in-the-loop governanceStatic HTML blueprint
Read the full specification

If you build or hire around systems like this, say hello.

julia@jbroberg.com

← All systems