The agent org
GreatBook runs five agents. Each is one LangGraph state machine with one lane, and the boundaries between them are structural rather than conventional. The organising principle is worth stating before the table: an agent’s authority is a property of its code, not of its prompt. The Auditor cannot write because its database sessions are read-only. The Typewriter cannot post because nothing in its package imports anything that can. No system prompt is load-bearing for any of it.The merged MCP staged-domain adapters do not expand an agent graph’s authority.
They are separate server-owned commit boundaries for exact W3 Matching decisions, Typewriter approval/submission, adjustment decisions, fiscal-period transitions and workflow resume.
Each rechecks the verified human, organization, target version and canonical service contract; there is no generic agent action dispatcher.
The five
The Clerk
Documents in.
Classify against 146 types, extract, resolve masters, validate, flag, queue for review.
Writes to the queue, never to the ledger.
The Bookkeeper
One approved document to one balanced journal entry, behind a human posting gate.
The only agent on the write path.
The Auditor
Continuous assurance over the book of record: seven check families, a nightly sweep, a durable exception register.
Strictly read-only, enforced by the database.
The Accountant
Period close, adjusting entries and statutory reporting.
Proposes; never posts.
The Typewriter
Words and lists in, schema-conformant document proposals out.
Propose-only, with no write path at all.
What each one may do
The lanes
On the document lane, two humans answer two different questions and neither gate can be skipped from inside an agent. An Accountant adjustment joins only at the posting gate under its own named-human, proposer-not-checker control.The deployed set, and the rule that keeps it honest
The five served graphs are declared in two files, and only one of them is read at runtime.
So
agents/tests/test_served_graphs.py pins the two files equal and imports every declared entrypoint.
The build goes red if they drift.
Changing the set needs an image rebuild, not an environment override.
A sixth graph would also need an eval: test_every_served_graph_is_graded reads the deploy manifest and requires each served graph to be bound in the eval registry, so adding one without grading it turns the build red.
A development manifest also exists and lists more graphs, including a folded-in extraction agent whose capability now lives inside the Clerk’s registry-driven pipeline.
Those are not deployed.
The deploy manifest is the authority for what is actually served.
What they share
The agents share canonical contracts where agreement matters: the document registry, SOP access, model path, validation shapes and separation-of-duties rules. They deliberately do not share one database authority: Typewriter has no database session, Auditor and Accountant use the separately proven read-only channel, and workflow agents receive only the storage paths their lane needs.The shared substrate
Which common contracts exist, which agents use them, and why database authority stays lane-specific.
The SOP store
Nine Git-bound SOP datasets, per-agent read grants, and rulebooks generated from the code that enforces them.
Where the business logic lives
The dividing line between agent judgment, which is editable knowledge, and rules with ledger consequences, which are code.
Guardrails and refusals
Deterministic scope gates, canned declines, and the sandbox an untrusted document is read inside.
Related
- How it fits together - where the agents sit in the stack
- Tracing a run - what a run looks like, span by span
- Two gates, three people - the human side of the money path
- Capability map - the mechanisms these agents drive