Novadiem Studio's agentic engineering system for turning complex software briefs into reviewed, traceable delivery.
Explore the Bureau | Read the Novadiem case study | Browse the Records | Work with Novadiem
The Bureau routes work through isolated specialist agents, carries decisions forward in durable artifacts, and places explicit gates around review, external actions, and production boundaries. Novadiem uses it to plan, build, review, and document software across studio projects.
This repository is a public view of a working studio system. It is here for technical evaluation and to show how Novadiem approaches agentic engineering. It is not currently packaged or supported as a self-serve product.
Coding models can produce useful work, but a long software job still needs someone to hold the structure together.
A single session tends to accumulate several jobs at once. It interprets the brief, argues for an architecture, writes the implementation, and then reviews the choices it already made. Important decisions remain trapped in chat history. If the session is interrupted, the next one has to reconstruct what happened and decide which parts of the conversation were authoritative.
The Bureau moves those responsibilities into a workflow:
- Tasks are classified before an agent is chosen.
- Specialists work in fresh contexts with narrow responsibilities.
- Handoffs are written to files, not left in conversation history.
- Reviewers see controlled evidence instead of the discussion that produced it.
- Human judgment remains at genuine product forks and external-action boundaries.
- Interrupted work resumes from state and artifacts on disk.
The model is one component. The routing, boundaries, evidence, and paper trail are the system.
The default topology has two coordination layers. The Delegate manages routine flow and gates. It keeps one resumable Conductor, which dispatches fresh specialists and adjudicates their findings.
flowchart LR
A["Human brief"] --> B["Delegate<br/>flow and gates"]
B --> C["Conductor<br/>dispatch and adjudication"]
C --> D["Fresh specialist<br/>bounded context"]
D --> E["Artifact on disk"]
E --> F["Cold review"]
F -->|revise| C
F -->|proceed| G["Reviewed plan or<br/>dev-verified build"]
B -->|genuine product fork| H["Human decision"]
H --> B
The exact path depends on the task. A bug fix does not need the same ceremony as a new product feature. The Conductor reads the workflow registry, selects the smallest fitting workflow, and records that choice before work begins.
Specialists are spawned without the manager's conversation. A reviewer does not watch a design get negotiated and then pretend to encounter it for the first time.
For integrated checkpoint review, the Bureau stages a bounded packet, excludes the live run log and transcript-like material, and asks an ephemeral reviewer for a structured verdict. The packet and verdict are tied to the artifacts being reviewed. See the host runtime contract and the integrated Delegate bridge.
The conversation is not the source of truth. A run writes its state, decisions, specifications, plans, reviews, prompts, and build evidence into a dedicated directory. Another Conductor can resume from that record without inheriting the previous session's transcript.
Anatomy of a Run walks through the paper trail in plain language. The mechanical contract lives in the run protocol.
The Bureau can continue through routine, written gates. It stops when the remaining question requires a product choice, new authority, or an external action that the task did not already authorize.
Build workflows stop at the development boundary unless a separate, explicit production action is approved. The standing rules are documented in the Conductor gates and the external-action boundary.
Code-changing runs receive their own branch and worktree. Concurrent runs can work against the same repository without sharing a checkout or writing directly to the integration branch. The worktree lifecycle is defined in the git worktree contract.
The close-out record distinguishes exact, estimated, inferred, partial, and unavailable evidence. Missing provider data is recorded as unavailable rather than counted as zero. See run accounting.
Repeated failures are promoted into conventions, scripts, or committed regression fixtures. The standing regression suite protects mechanical guarantees such as artifact binding, verdict validation, run isolation, accounting integrity, and fail-closed gates.
The suite and its promotion lifecycle are documented in .bureau/regression/README.md. Framework-level consistency checks live in check-framework.sh.
The Bureau is a dispatcher, not one fixed pipeline. Its registered workflows currently cover:
| Workflow | Purpose | Typical result |
|---|---|---|
feature |
Define a substantial feature or new product | Requirements, architecture, plan, and scoped prompts |
bug-fix |
Reproduce, locate, fix, and verify a known defect | Code change, regression test, cold diff review, and dev verification |
build-review-cold |
Build a contained change with risk-triggered cold review | Dev-verified change with review when silent failure is plausible |
execute-plan |
Turn an approved plan into vetted prompts and build them | Isolated implementation with per-part review |
design-build |
Implement an existing design handoff | Design manifest, build prompts, implementation, and fidelity review |
code-review |
Review a branch, pull request, diff, or working tree | Findings-first cold review with no edits by default |
docs-reconcile |
Reconcile planning or status documents with code | Updated documents rechecked against repository ground truth |
operational-build |
Run a defined build or operations runbook | Verified build or operations record, stopping before production |
message-framing and copy-review |
Frame and review public-facing language | Audience-aware copy with a separate voice pass |
write-article |
Produce a long-form article through staged review | Versioned drafts, grounding, cold proof, and a publish gate |
The complete and current list lives in workflows/index.md. A task that does not fit an existing entry triggers workflow definition instead of being forced through the feature pipeline.
The names give the system a memorable working language. The responsibilities remain concrete.
| Role | Responsibility |
|---|---|
| The Delegate | Routine flow and checkpoint gating at the top level |
| The Conductor | Triage, dispatch, adjudication, state, and close-out |
| Analizer 2000 | Requirements, assumptions, edge cases, and acceptance criteria |
| The Architect | Architecture, dependency mapping, and phased plans |
| The Challenger | Cold review of specifications, prompts, code, and evidence |
| The Cleric | Design need, design handoff, and fidelity review |
| The Spellwright | Scoped build instructions from approved plans |
| The Mage | Frontend implementation |
| The Systemsmith | Backend implementation and contracts |
| The Mechanic | Builds, infrastructure, and operations tasks |
| The Counselor | Audience framing and public-copy review |
| The Witness | Cross-run status and studio briefings |
| The Coupler | Verification where parallel build surfaces meet |
| The Notary | External cold attestation of a sealed artifact packet |
Cast identities and voice live in LORE.md. Mechanics take precedence when lore and runtime behavior differ.
Each task owns one RUN_DIR. For a targeted repository, new runs live under:
<target-repo>/.bureau/runs/<yyyymmdd>-<task-slug>/
The exact artifact set depends on the workflow. Common files include:
| Artifact | Purpose |
|---|---|
state.json |
Short, machine-readable run state |
log.md |
Append-only human record of spawns, decisions, findings, and handoffs |
model-routing.json |
Runtime, model, and reasoning assignment by role |
spec.md |
Requirements and architecture when the workflow calls for them |
plan.md |
Phased delivery plan |
prompts.md or a prompt folder |
Approved, scoped build instructions |
design/ |
Design brief, handoff, and manifest when a visual surface is involved |
coupling/ |
Evidence from cross-surface integration checks |
regression/ |
Run-local regression fixtures before promotion |
accounting.json |
Close-out record with evidence confidence |
The artifacts allow concurrent runs, inspection after the fact, and recovery after a session ends.
The Bureau separates provider-neutral model routing from the host transport that creates agent contexts.
| Runtime | Agent host | Status |
|---|---|---|
| Claude | Claude Code Agent tool | Supported |
| OpenAI | Codex collaboration tools | Supported |
| Codex | Alias for OpenAI at startup and reviewer boundaries | Supported |
| OpenRouter | Model routing only | No native run transport; fails closed |
| Hermes | Model routing only | No native run transport; fails closed |
Every specialist receives an explicit model assignment from the run's routing file. The framework does not silently inherit the manager's model. Current mappings and known accounting gaps are documented in docs/host-runtime.md, model routing and cast, and config/runtimes/README.md.
| Path | What it contains |
|---|---|
agents/ |
Specialist contracts, output formats, and boundaries |
workflows/ |
Task-specific routing and execution paths |
docs/ |
Runtime, run-state, gate, worktree, accounting, and convention contracts |
scripts/ |
Deterministic helpers for startup, verification, review, accounting, and close-out |
config/ |
Model policy, runtime adapters, schemas, and experiments |
templates/ |
Run state, project context, accounting, and decision templates |
.bureau/regression/ |
Committed regression fixtures for framework behavior |
reference/ |
Visual references and design canon |
The public README describes the system. The operational contracts remain in the repository:
- Codex entrypoint and repository rules:
AGENTS.mdandCODEX.md - Claude Code entrypoint:
CLAUDE.md - Workflow selection:
workflows/index.md - Run lifecycle:
docs/run-protocol.md - Host transport and isolation:
docs/host-runtime.md - Existing-project behavior:
docs/existing-project-mode.md - Worktree isolation:
docs/git-worktree.md - Gates and external actions:
docs/conductor-gates.mdanddocs/external-action-boundary.md - Accounting:
docs/run-accounting.md - Script reference:
scripts/README.md - External dependencies:
DEPENDENCIES.md
These documents assume a capable operator working from the repository. Novadiem does not currently provide a beginner installer, hosted control plane, or general installation support.
The Bureau is in active development and changes as Novadiem learns from real runs. Interfaces, workflow contracts, model mappings, and operator instructions may change without a stable release boundary.
The repository is public so clients and technical peers can inspect the work. If you want the Bureau applied to a product, an existing codebase, or an agent workflow, work with Novadiem.
No open-source license is currently attached to this repository. Public visibility should not be read as a supported self-serve distribution. Contact Novadiem Studio to discuss project use or commercial terms.
- The Bureau, the public site, cast, records, and visual system
- Novadiem case study, the studio view of the system and the problem it addresses
- The Harness Is the Product, why the coordination layer matters
- Who Checks the Checker?, what happened when several reviewers agreed and the repo-aware reviewer did not
- Gate the Flow, Not the Judgment, how routine gates differ from product decisions
- The Pipeline That Wrote This, a Bureau workflow described by an article it produced
- The Gates, the standing decision boundaries
- Cast and Routing, the public map of roles and handoffs
The Bureau is part of how Novadiem Studio delivers software. It is not the service by itself.
If you have a product to define, a difficult codebase to move forward, or an agent workflow that needs stronger structure and review, start a conversation with Novadiem.