ApexCorpWhat actually happens between your brief and a result
ApexCorp is not a prompt chain wearing job titles. The parts that matter — who may route, who may approve, who may write to which memory pool — are enforced in a domain model that an agent has no way to talk past.
The lifecycle of a task
- 1. You describe the company
- A sentence or two about what it does. That brief is the only structural input — teams, leaders, and a QA team sized to headcount are derived from it.
- 2. The Manager proposes a structure
- It drafts an org chart and files a note asking you to approve it. It cannot adopt its own proposal: the function that approves a structure takes a person’s name, not an agent id.
- 3. You give the company work
- A title, optional detail, and an urgency flag. Work enters a backlog rather than starting immediately.
- 4. The Manager routes and sizes it
- A team is picked by the nature of the work, then that team’s leader picks who. The task is classified simple, standard or hard and sent to the matching model tier.
- 5. An agent does it
- Under an iteration cap, a spend ceiling, and a read-only tool surface confined to the project root. Every tool call is published to the live feed.
- 6. QA reviews the result
- Completed delivery work is handed to the QA team as an ordinary task, so it gets the same rails. A review inherits the complexity of what it reviews and never costs more than the work did.
- 7. Anything unresolved reaches you
- Not enough information, no clear owner, an outward action, a rail tripped — all of it becomes a note in one queue, resolved by a person and never deleted.
Two tiers of routing
A single router that picks one agent out of nine has to know everything about everyone. ApexCorp splits the decision: the Manager chooses a team by the nature of the work, and that team’s leader chooses who within it — a member whose specialty fits, or itself if none does.
A leader keeping the task is a normal outcome, not a fallback failure. And when nothing fits, the answer is a note asking you for an owner rather than a confident guess that sends the work to the wrong desk.
Memory is scoped, and approved
Every agent reads the company pool on every turn, so a fact earns a place there only if all teams need it. Everything else stays local to the team that learned it. That is a token decision as much as an organizational one.
member ──proposes──▶ team leader ──approves──▶ team memory leader ──proposes──▶ Manager ──approves──▶ company memory
Nobody approves their own proposal and nobody skips a rung — a member cannot propose straight into company memory. Both rules live in the domain layer with tests on them, not in a system prompt. An accepted proposal credits the proposer as author, so provenance follows the work rather than the approval.
The model is chosen per task
This is the single largest cost lever in the system — roughly a 5× swing on input and output between tiers.
- simple · Haiku 4.5
- Typos, renames, readme edits, lint, formatting.
- standard · Sonnet 5
- Everything else. Ordinary delivery work, at high effort.
- hard · Opus 5
- Migrations, refactors, audits, investigations, or any brief long enough to imply depth. Hard wins ties: under-powering deep work costs more in retries than the upgrade would have.
Agents act through a small, read-only surface
Everything that changes the world goes to the notes queue instead. That is the no-unattended-outward-actions rule expressed as a tool set rather than as an instruction an agent could reinterpret.
- read_file and list_files — confined to the project root. Every supplied path is resolved and checked twice: lexically, and again after following symlinks. Percent-encoded separators and null bytes are refused rather than decoded.
- run_command — DevOps only, against an allowlist rather than a blocklist. Shell operators are refused and commands run without a shell, so the allowlist cannot be re-parsed around.
- remember, propose_company_memory, raise_note — the approval chain and the escalation channel.
A refused tool returns an error result rather than throwing, so the agent sees “that is not allowed” and adapts instead of having its run torn down.
Declared versus observed
The panel keeps two graphs of the company. Declared is the org chart: who reports to whom, the authority structure. Observed is what actually happened — who routed work to whom, who reviewed whose output, whose proposal someone accepted.
They diverge, and the gap is the interesting part. It is how you notice that QA reviews far more than the chart implies, or that two teams have quietly started depending on each other.