The Architecture: Five Governance Questions, Enforced

The anatomy

A seat, defined.

Every seat is defined before it is given any work. What follows is what the architecture holds it to, question by question.

An agent seat is not a prompt. It is a defined position: a persona and the doctrine it holds, the skills it is competent to be handed, and a spend cap it cannot exceed. Around it, the architecture holds the rest: one global tools suite the stage draws from per invocation, one sacred-path policy every seat is refused, and a shared bank of gates that reviews what it produces.

The five questions below are answered before any work is dispatched: some at the seat’s own definition, the rest by the architecture it runs inside. A seat cannot widen either one, and no instruction reaching it at runtime can either.

One seat, up close

Senior Backend Engineer

Graduated · Full Pipeline

Persona: 312linesDirect, terse, tests first.
Doctrine · Earned in Production41earned rules
Never opens a PR on a red baseline; reads the last run on the target branch first.
Splits schema changes from behavior changes; one merge, one risk.
Treats a flaky test as a defect, not a retry.
Skills: APIs · migrations · queue design
Tools: 58in the suite · deploy: nonerepo.read · repo.write · ci.run · db.migrate (staging only)One global tools suite. The stage attaches what a step needs, per invocation.
Caps: $5.00 per task · the breaker trips at the cap · escalation goes to a person
Sacred: 23paths · one policy, every seatdeploy/** · billing/** · secrets/**Declared once in your configuration. The seat gets its touch scope per task.
Review: The shared gate bank: Security, QA, and Code Quality. No seat reviews its own work.

A job description, not a prompt. Hundreds of lines per seat, earned in production, ratified by a person.

Frontend Engineer287 lines · 34 rules

Platform Engineer356 lines · 38 rules

Data Engineer298 lines · 31 rules

Integrations Engineer341 lines · 44 rules

Database Administrator372 lines · 27 rules

Security Reviewer418 lines · 22 rules

Compliance Analyst393 lines · 18 rules

Access Reviewer264 lines · 16 rules

Privacy Reviewer307 lines · 19 rules

Threat Modeller384 lines · 21 rules

QA Lead329 lines · 29 rules

Test Engineer276 lines · 33 rules

Code Reviewer361 lines · 24 rules

Release Manager338 lines · 36 rules

Performance Analyst292 lines · 26 rules

Product Manager347 lines · 17 rules

Business Analyst281 lines · 14 rules

Solution Architect402 lines · 23 rules

Technical Writer258 lines · 12 rules

Support Lead313 lines · 20 rules

Site Reliability Engineer441 lines · 39 rules

Incident Responder396 lines · 32 rules

Observability Engineer351 lines · 35 rules

Cost Analyst269 lines · 15 rules

Change Manager322 lines · 18 rules

Migration Engineer368 lines · 30 rules

API Designer294 lines · 25 rules

Build Engineer333 lines · 37 rules

Schema Owner379 lines · 28 rules

Records Custodian253 lines · 13 rules

Policy Author316 lines · 16 rules

Vendor Reviewer271 lines · 14 rules

Audit Liaison344 lines · 19 rules

Accessibility Reviewer288 lines · 21 rules

Regression Analyst359 lines · 27 rules

Fixture Curator262 lines · 23 rules

Design Reviewer297 lines · 18 rules

Localization Editor254 lines · 12 rules

Research Analyst326 lines · 15 rules

Onboarding Lead283 lines · 17 rules

Billing Analyst309 lines · 16 rules

Pricing Analyst274 lines · 13 rules

Capacity Planner337 lines · 22 rules

Backup Steward363 lines · 26 rules

Network Engineer391 lines · 31 rules

Runbook Author267 lines · 14 rules

On-Call Scheduler279 lines · 19 rules

Query Optimizer318 lines · 24 rules

Cache Engineer286 lines · 29 rules

Data Steward353 lines · 22 rules

Dependency Auditor348 lines · 17 rules

Key Custodian366 lines · 12 rules

Contract Tester273 lines · 31 rules

Content Strategist304 lines · 13 rules

Requirements Analyst331 lines · 15 rules

Field Enablement Lead268 lines · 14 rules

Log Analyst291 lines · 20 rules

Rollout Engineer374 lines · 33 rules

Escalation Lead259 lines · 16 rules

Chaos Engineer407 lines · 36 rules

Every seat is defined exactly this way.

The lifecycle

A goal becomes signed, shipped work.

The machine does the work and stops itself at every gate. You hold two: you approve the scope before anything starts, and you sign the merge before anything ships. That holds until you graduate the instance, and code still comes to you afterwards.

The loop

01
Goal inin
A Brief enters, from you or pulled from Jira.
02
Feature specmachine
Scope, acceptance criteria and a cost band, written first.
03
Approve scopehuman
You ratify the scope before any work starts.
04
Architecture reviewmachine
The approach is checked before a line is written.
05
Buildmachine
Agent seats write the code.
06
Security reviewmachine
The change is read for security flaws.
07
QA and testsmachine
A QA seat validates it against the acceptance criteria.
08
Independent reviewmachine
A different seat reviews the diff, never the one that wrote it.
09
Documentationmachine
The docs are updated with the change.
10
Preflightmachine
Final checks before it leaves the org.
11
Open a pull requestmachine
A pull request is opened against your own repo.
12
Sign and mergehuman
Your signature goes on the record, then it merges.
13
Shipped to productionout
Merged and deployed, with a forensic receipt.

Q1 · What can it touch?

What can it touch?

A seat is granted a path list, never a repository. Sacred paths are declared once, in your configuration, and enforced at the gate: a change that reaches outside them does not become a pull request.

Tools come from one suite, and the stage attaches only what a step needs, per invocation. A seat that writes documentation is never handed a deploy tool, and nothing it reads during a task can hand it one.

The gate bank runs on the diff, not on stated intent. It reads what the change actually touched, and out-of-bounds work stops inside the org.

A change held at a gate under a blocked-for-sacred-path refusal, then passing the same gate after it is rebuilt. — An out-of-bounds change stops at the gate bank, before a pull request exists.

Q2 · What can it spend?

What can it spend?

Every seat carries a cap on what it can spend in a day, and no single call can exceed a hard per-call ceiling. Above both sits an org-wide daily halt, because caps that bind one seat at a time do not bound the org’s total.

All three are checked before the model is called. A cap refusal is a refusal: the task stops, the reason it stopped is recorded, and nobody is handed a warning they can dismiss.

You set the caps before the org is given any authority at all, and raising one is a decision a person makes, on the record. Every call is then written down at micro-dollar precision, against the seat that made it and the task it belonged to.

A spend meter stopped at thirty dollars against a thirty dollar daily cap, with the refusal shown under it. — Spend is checked before the call and written down after it. The cap is a stop, not a threshold.

Q3 · Who approves?

Who approves?

The org proposes. A person ratifies. That order does not invert, and there is no configuration that inverts it.

Roles sit under one chain of command, and nothing self-approves. The seat that wrote a change is never the seat that reviews it, and no seat is ever the human.

An approval is a named person against a named decision, held on the record with the work it authorised.

A drafted proposal returned as ratified, signed by a named human against a named decision. — Authority moves one way. Nothing in the org can approve its own work.

Q4 · What ships?

What ships?

Work crosses a review bank before it can leave the org: the approach, the security read, quality against the acceptance criteria, an independent read of the diff, the docs, and preflight.

Then it stops at a person. A pull request opens against your own repository, and it merges when a human signs it. Your signature is what ships the work.

A new deployment starts in probation: the org reads, drafts, and proposes only, until you graduate it.

Work held at the signature gate, and the shipped count ticking up once a human has signed it. — The review bank is machine work. The last gate is not.

Q5 · What got logged?

What got logged?

Every action lands on the record as it happens: the seat that took it, the task it belonged to, the tools it called, the money it spent, each gate result, and the signature that released it.

Click any shipped item and walk its full history back to the goal that started it. The question an auditor asks is answered by opening the item, not by reconstructing it.

The record is written to your database, on your own infrastructure. Nothing about the run has to leave it.

The roll-up

The record becomes the executive report.

Nothing is re-keyed. Every figure a board asks for is already on the record, because a governed run writes it as it happens.

An executive report standing complete over a thirty-day window, assembled from the record a governed run wrote. — The report is a read of the record, not a second system anyone has to maintain.

The whole of it

Five agents or five thousand…
one chain of command.

Same five questions, same answers, at any size. The architecture is what makes that true.

Request a briefing→Where it runs→Read the research→