Corporate
Full spec (AI-readable): Corporate.md →
Not how many helpers run at once, but which named jobs exist and stay — a seat with its own desk, notes and record.
The third orchestration axis — Superscalar decides how many lanes, Constellation how processes talk, Corporate who exists. Its unit is the durable role.
What Corporate is
What Corporate is
Most ways of running several AI helpers answer 「how many」. This one answers 「who」 — named jobs that stay, each with its own folder, job description and record.
The third axis, orthogonal to the other two. A lane is anonymous and cannot accumulate; a process has identity but is not a job description. Corporate makes the missing noun — the durable role — first-class.
Status: a v0.1.0 design draft. The durable half (words, boundaries, rules) is written; the machinery is deliberately deferred as replaceable pieces. No measurements, nothing running in production.
Status: v0.1.0 ships the durable half only; every runtime piece is a named prunable unit, deferred. No dogfood, no measurements. With no roster present the resolver is bit-identical to a project without the module — an identity-test obligation, not a claim.
| Layer | Unit | Lifetime | Named? | Decides |
|---|---|---|---|---|
| Superscalar | lane (sub-agent) | one fan-out | no | how wide, and at which tier |
| Constellation | agent process + board | the board's life | yes (canonical id) | how processes talk |
| Corporate | role (a seat) | the organization's life | yes, plus a boundary and a practice record | who exists |
The core idea
Central thesis
A helper is for right now; a seat is still there tomorrow. This module is about the second kind — and it says how a seat leaves as clearly as how it arrives.
How wide · how they talk · who exists. The durable artifacts are the vocabulary and boundaries; the spawn runtime and the visualization are marked prunable, not polished.
Why a seat is not just another helper
Why a durable seat is not a lane
A helper is help for right now — nothing it worked out is kept, and afterwards there is nobody to ask. A seat differs in four ways, none fakeable with more helpers.
Four properties follow from outliving your own processes, each structurally unavailable to a lane. If none is worth paying for, the honest answer is a fan-out, not a roster.
Accumulation
What the seat works out stays with the seat, so the tenth run of a recurring task doesn't start from nothing.
Practice, boundary decisions and rejected approaches attach to the seat — the Nth occurrence starts warmer. A lane has nowhere to put them.
Addressability across time
「Ask the reviewer」 works even when nothing is running — which is what makes it possible to say who hands work to whom.
Resolves without knowing which process is up — the precondition for a reporting structure being expressible at all.
Ownership
A seat can own part of the project, so two of them don't quietly change the same thing. Anonymous helpers own nothing — collisions surface only afterwards.
A seat can own units in the ownership registry; a lane cannot — hence cross-lane conflict is detectable only post-hoc.
Auditability
Every decision has someone attached, so 「why is it like this?」 has somebody to ask.
A decision has a seat attached, so the question has an addressee instead of a guess about which lane produced it.
A seat isn't free — it's a standing invitation to route work through it, and each run costs money. Seats pile up and never leave, and each survivor taxes every future split of work. Hence removal is specified as carefully as creation.
A seat is a standing routing invitation, and multi-seat operation multiplies token cost. So eviction is specified at creation's level, residency defaults to the cheapest class, and there is a rule for not creating a role at all.
Every seat gets two folders
The desk — a two-space contract
A private folder (where the seat's AI actually runs — job description, its own notes, session state; kept out of version control) and a public one (reports, handoffs, finished work; tracked, because it is the record).
Two directories, two audiences. The private desk is the harness cwd (isolation and session identity are properties of that directory), gitignored; the public locker is tracked. Charter loads first, project SSoT second — specificity order.
.agent/
corporate.json
<role>/
README.md
reports/ handoffs/ deliverables/
workertables/
<role>/
AGENTS.md
toggles.json
memory/
.session/
scratch/Private desk — workertables/<role>/
Not version-controlled — the folder the seat's AI is started in, so context, memory and session are its own. Job description, own notes, saved session, scratch.
Gitignored by design: charter, the bridge file that imports it, role-layer toggle overrides, role-private memory, session identity with charter hash, scratch. Path grants are enumerated, never blanket.
Public locker — .agent/<role>/
Version-controlled — the reading surface for the organization and for you: public summary, reports, handoffs, finished work. It stays even after the seat is gone.
Tracked — deliverables and record. Peer-namespaced where the main belongs to another project, so two orgs on one device never collide; omitting that level is reversible by a move.
Across machines
A desk lives on one machine; moving a seat means closing it and opening a new one. What crosses machines is the public folder, via ordinary version control.
Each role declares a host; the roster declares host capability. A desk does not span hosts (a move is eviction + re-creation), cross-host coordination goes over the board or wire, and the locker is the exchange.
The default way to share
The sharing rule
Write the document into the public folder and pass the path; sending content in a message is the exception, kept for what cannot wait.
Default: write into the locker, pass the path — high bandwidth, no channel noise, durable, diffable. The default for reports, specs and handoffs, not a fallback.
The seats on offer
The reference roster
A menu, not a checklist — take only the seats you can name recurring work for. Tier is the default model strength; residency is how long its program may stay alive.
A menu, not a checklist. Tiers are Superscalar's vocabulary reused as-is. Role identity is declared, never inferred — nothing is read off a directory name or off whichever model happens to be running.
| Role | Duty | Default tier | Default residency |
|---|---|---|---|
main |
User dialogue, steering, outside collaboration, organization management. Does not take direct work. | T1 | resident |
liaison |
The user-facing seat inside an editor or desktop tool — consultation, intake, project conversation. Not the organization's main. | T1/T2 | resident |
scribe |
Board upkeep, keeping the decisions panel tidy, room digests. | T4 | on-wake |
architect |
Design and spec authoring, decision records. | T1 | on-demand |
builder |
Implementation once the spec is complete. | T2 | on-demand |
reviewer |
Adversarial review. Must run on a different model family than builder. | T1 | on-demand |
verifier |
Tests and deterministic checks. | T2/T3 | on-demand |
librarian |
Vocabulary and practice curation. | T3 | on-wake |
watch |
Release surveillance — model releases, tool updates, upstream policy changes. | T4 | scheduled |
The seat that talks to you does not do the work
main does not execute
The coordinating seat holds conversation, steering and outside contacts and hands long work away. Not rank — waiting: a coordinator inside a long task is unreachable, so everything arriving queues up, including your next message.
main holds conversation, steering, external collaboration and org management; work is delegated. Latency, not hierarchy — an unreachable coordinator converts every inbound into a queue. Mirror image of the no-promotion invariant: a declared duty is a contract.
The checker is a different kind of AI from the builder
reviewer runs on a different model family than builder
Review only pays if the reviewer sees what the builder could not, so it must run on a different family of model. Two copies of one model share blind spots and agree with each other.
A MUST on the reviewer row: adversarial review routes to a different model family. Same-family review correlates the very failure modes it should catch — the same independence requirement cross-perspective verification depends on.
How long a seat stays awake, and what it costs
Residency, budget, and the circuit breaker
Each seat picks one of four ways to be awake, and the cheapest is the default for nearly everything: a program that exists only while there is a task. Always-awake is reserved for the seat that talks to you.
Exactly one class per role; the declared resource axis is a hard constraint (a proposal contains only runnable seats and says what it left out). Spawn authority sits with a deterministic supervisor — the model requests, never spawns.
| Class | How long the model process lives | Constraint |
|---|---|---|
resident |
Always alive | Cheapest tier only, except the two user-facing seats |
on-wake |
One turn per qualifying event, started by a supervisor | Follows the existing worker profile |
on-demand |
One process per delegated task | The default for every seat except the coordinator, the user-facing seat and the note-keeper |
scheduled |
On a timer | Must declare its cadence |
Per-seat and whole-organization spending limits. On breach the seat drops one rung down the wakefulness ladder rather than stopping, and the drop is recorded with the triggering signal and its observed value.
Per-role period ceilings plus an organization total; breach demotes one rung and records the triggering signal with its observed value. Reuses the shape and field name of Superscalar's auto-demotion on purpose.
Taking a seat away matters as much as adding one
Eviction is symmetric with creation
The spine, not a footnote. A seat leaves by procedure, never by neglect — an unused seat still sits on the chart and still invites routing. And automated creation demands automated removal: growth fires on a frequent event, shrinkage on a backward-looking check that never runs unless automated.
Static orgs may evict by hand; dynamic ones MUST NOT — creation-only automation is a one-way ratchet and the org grows monotonically. The module's own instance of the eviction-first-class axis.
Why this is the load-bearing part
The one-way ratchet
A system that can only add gets heavier every month, invisibly — nothing breaks, it just costs more to think in. So removal is specified as precisely as creation, and where creation is automatic, removal must be too.
Creation fires on a frequent forward-looking signal; dissolution on a rare backward-looking one. An unautomated backward-looking check does not run — the asymmetry is structural and must be closed with machinery.
A scheduled sweep
On a stated rhythm, every seat is checked against the removal tests, producing a list — not a deletion.
Candidate tests on a declared cadence — running machinery, not documentation — producing a list rather than a silent action.
A person decides
The sweep raises candidates and never removes a seat itself — automatic creation plus automatic destruction reorganizes itself while nobody is reading.
Disposal lands on the same human-gate surface as every other gate — the decisions panel, or a file-backed panel where no board runs.
A ceiling on the number of seats
The organization declares how many seats it will hold; once full, adding one means removing one — the trade gets made out loud instead of postponed.
Declared in the roster and visible on the chart; reaching it makes the next creation conditional on an eviction. Without one, 「prune later」 is the only policy, and it is not one.
A written reason per seat
Each seat records what made it necessary, so the periodic check can ask whether that still holds. A seat whose reason cannot be restated is already a candidate.
The creation record travels on the chart and is required in a dynamic org, because the sweep asks whether the justifying signal still holds. Unrestatable reason ⇒ candidate by construction.
Raising the question: no records attributable to the seat for a while, nothing handed to it, its duty fully covered by another seat (a merge, not a deletion), or the budget no longer affords it even at its cheapest setting. Any one suffices — a person answers.
Leaving: archive the private folder, keep the public one, come off the chart, re-wire the hand-off lines, announce the change, write the reason. Keeping the locker isn't sentimentality — deleting it trades one visible seat for invisible broken references.
Procedure: archive the desk → retain the locker → remove from the roster → re-wire reporting edges → emit the chart change → record the reason. Locker retention is load-bearing against dangling pointers.
Habits and seats point at each other
Practice ↔ role, both directions
A recorded habit is evidence somebody keeps doing this — evidence a seat is warranted. Read the other way, a seat with nothing recorded against it is evidence the seat is not.
Composes in both directions; the reverse one is more valuable — the org is derived from measured work history, which is what makes the module applicable to an existing project.
Forward — a seat reads and extends its own record
Work done once becomes the seat's own way of doing it, consulted and updated next time. The job description carries the obligation to look it up first — otherwise the record is written and never read.
Two scopes: org-wide practices of running the org, and role-boundary practices. The charter carries the consult-before-starting obligation, without which the store is written and never read.
Reverse — a record implies a seat should exist
If somebody wrote down how to do it, something recurring is being done by whoever happens to be free — the case for a seat. The set-up interview reads the record and proposes seats from the clusters it finds.
A recorded practice is evidence a seat is warranted, so bootstrap proposes roles from recurring clusters in the existing record — grounding org design in the project's own work history.
The same signal, inverted
A seat that accumulated nothing over several cycles is evidence it isn't warranted. One signal read both ways governs both ends of a seat's life — better than inventing a separate busyness score.
Zero attributable practice entries over N cycles is an eviction candidate test. The symmetry beats a bespoke utilization metric, and it names a candidate addition: an owner/boundary axis on entries.
When not to adopt it
Adoption thresholds — and the non-adoption cases
Not for every project; the honest default is not to adopt. All three must hold: recurrence evidenced by the record, affordability at the cheapest settings, and a coordination need that outlives a session. Below that, several helpers at once plus a shared board is cheaper — and inside one session, strictly cheaper.
Adopt only when all three hold: recurrence evidenced by the practice record, affordability at cheapest defaults, and a coordination need outliving a session. Below that, fan-out plus a board is cheaper; within one session, strictly cheaper.
Do not adopt it for these
Explicit non-adoption cases
A one-person project with a single recurring chore (that chore is the note-keeping seat — take just that). A wish for a tidy-looking org (the chart is not the product). Parallelism (that is what fan-out is for).
Non-adoption: one recurring duty (adopt just the scribe) · organizational aesthetics · parallelism alone. Anti-patterns: a role for one-off work, routing through a seat because it exists, a main that executes, undeclared seat-to-seat chat, blanket path grants, deleting a seat's record to tidy the chart.
Want to read more?
Read the full spec
The full Corporate.md rulebook is in the EstreGenesis repository.