The Bureau's orchestration topology drawn as a gilded observatory: a bright central hub with spokes radiating to a ring of satellite stations, gold filigree and cyan filaments on midnight navy
The Hub — one Conductor at the centre, each specialist a station on its own spoke.

Case Study · AI Systems

The Bureau

The studio's own multi-agent development framework. One orchestrator routes each task to specialist AI agents in isolated contexts, and every run leaves a written record you can audit, resume, or archive.

Site
thebureau.dev ↗
Status
In active use · runs the studio's own builds
Disciplines
AI systems architecture · Multi-agent orchestration · Developer tooling
Stack
Claude Code subagent orchestration · provider-neutral model routing · file-based run artifacts · git-worktree build isolation

The problem

Work with an AI coding assistant for a week and two failures surface. The first is amnesia. Every session starts from zero: the decisions, the rejected approaches, and the reasons behind the architecture live in a scrollback buffer that's gone by morning. The context window is a workspace, not a record, and the standard tooling does nothing to turn it into one.

The second failure is quieter and worse. Ask the model that just designed a system to review that design and it will find very little wrong. It isn't lying; it's rereading its own reasoning and agreeing with it. Analysis, design, build, and review all happen inside one context that has already argued itself into the plan. A reviewer that watched the argument get made isn't a reviewer.

What was built

The Bureau is a multi-agent development framework built on Claude Code. The main session becomes the Orchestrator, called the Conductor, and it does no specialist work itself. It triages each task, then spawns the right specialists as real subagents, each in a fresh context: an analyst for requirements, an architect for design, a critic for review, a prompt engineer for build instructions, and a build crew for code. The agents share the filesystem, not the conversation. Work crosses between them only as written artifacts, and that isolation is what makes the review honest.

It's private infrastructure, not a product for sale. Novadiem built it for its own work and runs its own builds through it, which is why it belongs in a portfolio: the framework's output is public and checkable, starting with the other case studies on this site.

How it's built

One conductor, a cast of specialists, and gates that don't bend.

No single clever prompt. Reliability comes from structure: isolation makes review mean something, routing keeps costs proportionate, and artifacts make every run auditable and resumable.

The Bureau's feature workflow drawn as an assembly line: a raw idea enters at left and passes through the Conductor, the analyst, and the architect, past a human checkpoint, through two cold reviews by the Critic with a design handoff in the middle, and exits at right as vetted, scoped build prompts. Each step names the artifact it produces: spec.md, plan.md, prompts.md.
The feature workflow end to end. A raw idea enters at left; vetted, scoped build prompts come out the right, having passed two cold reviews on the way. Every step writes an artifact to disk.
01

A dispatcher, not a doer

The Conductor triages every task against a workflow registry and runs the smallest workflow that fits. A bug fix, a copy pipeline, and a new feature get very different treatment; the full team only assembles when the task earns it. The Conductor spawns, routes handoffs, and rules on verdicts. It never writes the spec, the critique, or the code itself.

02

Review that stays cold

The Critic reads each artifact in a fresh context, having never seen the design get argued, and returns a binary verdict: APPROVED or REVISE. It runs twice in a feature workflow, once on the spec and plan, once on the build prompts. Findings route back to the owning agent at most twice; after that the framework stops and puts the question to a human.

03

Provider-neutral model routing

A policy file decides what runs where, not a hardcoded model name. Each role starts on a capable but cheaper tier, and the framework escalates to a frontier model on evidence, such as a final high-risk review gate. Every spawn names its model, and changing providers is a configuration change, not a rewrite.

04

Every run leaves a paper trail

A run produces its spec, plan, and build prompts, plus a human-readable decision log and machine-readable state. Those files are the only channel between agents, so the record is complete by construction. Any interrupted run resumes in a new session from its state file, and finished runs are archived whole.

05

Parallel builds in git worktrees

Each build run gets its own git worktree, so two jobs on the same repository can run at once without touching each other's files. One global install serves every project; each run owns its directory, its branch, and its state.

06

It ships, and it audits itself

The framework's own archive holds 34 completed runs, including the ones that built devweb.org and the Recallatron memory engine. An evaluation ledger records what each review pass caught and what changed in the framework as a result, so the process improves the same way the output does: on the record.

Claude Code subagent orchestration · JSON model-routing policy with runtime adapters · markdown agent personas · file-based run artifacts · git worktrees per build.

What this shows

Multi-agent AI is a process problem before it's a model problem.

The Bureau's useful properties don't come from any model. They're designed in. Isolate the reviewer and the review means something. Write every decision to disk and the work survives the session. Route by policy and no single vendor owns the system. That's the discipline Novadiem brings to AI work: agents as components in an engineered process, with gates a model can't talk its way past.

It's also not a thought experiment. The Bureau built devweb.org and the Recallatron, two other entries in this portfolio, and it runs the studio's builds today. A client weighing whether Novadiem can architect agentic systems doesn't have to take the framework on faith. The output is public.

spec.md plan.md prompts.md log.md state.json
Ω

Want systems like this around your model?

Model-agnostic LLM orchestration, agentic tooling, and the platforms they run on, designed and built from one practice.