Skip to content
CodeBook

Sheet 01 · The software factory builder

Assemble your software factory.

Assemble agents and crews into workflows. Set the checks, permissions and handoffs. Review changes before they reach the next environment. CodeBook runs it.

Get startedSee how it works

How, in one sentence · a board where the columns have workers.

Workers to hire
212
Line templates
47
Tool servers · MCP
50
Outside agents
via MCP
Pull requests
Draft only · never merged
A Feature development workflow with seven stations: Analyst, Design, Development, QA, Security, a human Approval gate, and Done. Each station has a worker and a status lamp. Cards move from station to station. When QA fails a card it goes back to Development with the evidence. At the Security station the card is sent to a second workflow, Security remediation — Triage, Fix, Verify — with a brief, waits, and carries on when that workflow sends it back. A person approves it before it is done.

Workflow 01 · Feature development

  1. ST-01

    Analyst

    Sarah

  2. ST-02

    Design

    Zoe

  3. ST-03

    Development

    Alex

  4. ST-04

    QA

    Maya

  5. ST-05

    Security

    Omar

  6. WF-02 · ST-01

    Triage

    Omar

  7. WF-02 · ST-02

    Fix

    Lin

  8. WF-02 · ST-03

    Verify

    Ravi

  9. ST-06

    Approval

    A person

  10. ST-07

    Done

    Finished

QA fails a card back to Development with the evidence. Security sends a brief to a second workflow, waits, and carries on when it returns.

RunningPassFailWaiting · gate

01The argument

Don’t build your own software factory. Assemble one.

Coding agents and agent crews are getting good at manufacturing software. Then every team is told to build the factory around them.

Somewhere to queue the work. A pipeline to move it. Something to supervise the loop that will not end, decide who is allowed to touch the repository, and keep a record of what happened. None of that is the agent. All of it is a factory — and it usually lands on your roadmap as nine projects nobody planned for.

CodeBook is that factory, ready to assemble. You lay out the lines, staff the stations and set the rules; the platform runs them. Agents you already use — Claude Code, Codex, Kiro, Devin — can work inside it as MCP clients driving a workflow, and GitLab CI/CD, CircleCI, Buildkite, Cursor, Jules and GitHub Copilot have adapters of their own.

  • Instead of building Memory

    The card carries it

    Fields, discussion and the last station’s output travel with the work, and conversations keep their history.

  • Instead of building Scheduling

    Triggers

    A card dropped, created or commented on starts the station’s worker.

  • Instead of building Queues

    Stations

    Every column is a queue with one worker, and a duplicate event finds the first job instead of starting a second.

  • Instead of building Pipelines

    Pass · fail · blocked

    Each station says where the card goes next — inside the line, or to another workflow.

  • Instead of building Supervision

    Bounded retries, then a person

    Loops stop at the retry limit and escalate. The factory overview shows what is running, waiting and blocked.

  • Instead of building Governance

    Human gates

    A station a person holds, or an agent that runs only after approval. The platform holds the gate, not a prompt.

  • Instead of building Permissions

    Per-station grants

    Draft pull requests and tools are off until you allow one station. MCP tokens are scoped to one workflow.

  • Instead of building Audit

    The run record

    Every step and every tool call is kept, and the verdict is written on the card.

  • Instead of building Multi-agent coordination

    Handoffs with a typed brief

    Move, send, or send and wait — goal, evidence and open questions — along routes you declared.

02Legend

A board where the columns have workers.

That is the whole idea, and everything else is built up from it. A column is already a job description — so CodeBook lets something hold the job. The words are a factory’s on purpose: it is the best-understood machine there is for moving work through specialists.

Legend

In CodeBook = on a factory floor

01Factory

= The floor

The operating environment for one team. It holds every line that team runs.

02Workflow

= Assembly line

A board. Build as many as the team needs.

03Station

= A column

One job, one worker, one definition of done.

04Worker

= Who does the job

An agent, person, crew, external runtime, or another factory through an intake.

05Card

= Work item

The whole brief: fields, checklist, attachments, discussion.

06Move

= Handoff

A card arriving at a station starts its worker.

07Gate

= Quality control

Pass, fail or blocked — and a person where it matters.

08Marketplace

= Workforce

Where you hire the agents that staff the stations.

How a factory works

03Floor plan

One factory. Every line the team runs. Lines that hand work to each other.

Features, bugs, incidents and security findings all move differently, and they touch constantly. Each is its own assembly line with its own stations and workers — and a station can route a card to another line on the same floor.

A factory called Payments engineering holding four workflows: Feature development, Security remediation, Incidents and Bug fixes. WF-01 QA hands off to WF-02 Intake: Send and wait. WF-02 Closed hands off to WF-01 Development: Returns. WF-03 Postmortem hands off to WF-04 Reported: Send. Every workflow shares the factory’s agents, repository, tools and audit trail.

Factory · Payments engineering

WF-01 · Feature development

  1. Backlog
  2. Design
  3. 2Development
  4. 1QA
  5. Approval
  6. Done

WF-02 · Security remediation

  1. 1Intake
  2. Triage
  3. Fix
  4. Verify
  5. 2Closed

WF-03 · Incidents

  1. Reported
  2. Triage
  3. Mitigation
  4. Verification
  5. 3Postmortem

WF-04 · Bug fixes

  1. 3Reported
  2. Reproduce
  3. Fix
  4. Regression
  5. Done

  1. 1 · Send and wait

    QA → WF-02 · Intake

    QA finds a security problem. The card goes to Security remediation with a brief, and the original waits.

  2. 2 · Returns

    Closed → WF-01 · Development

    Security closes its side and the card comes back to Development to carry on.

  3. 3 · Send

    Postmortem → WF-04 · Reported

    A postmortem files the follow-up as a linked card on the Bug fixes line, and the incident carries on.

Three ways to hand off

Move
The card leaves this workflow and lives in the other one.
Send
A linked copy goes to the other workflow, and this card carries on.
Send and wait
A linked copy goes, and this card holds until the other workflow sends it back.

Every handoff carries a typed brief — the goal, the evidence, the open questions. Agents can only hand off along routes you declared, and loops between workflows are bounded.

How workflows hand off

Factory overview

Illustration

WorkflowRunningWaitingBlocked
WF-01Feature development320
WF-02Security remediation100
WF-03Incidents110
WF-04Bug fixes231

The factory overview shows every workflow with what is running, waiting and blocked, and the traffic between them.

04Station anatomy

One station, taken apart.

Every station says who works it, what starts them, what they may read and touch, and where the card goes when the work passes, fails or is blocked. That is the whole routing model — and it is configuration, not a prompt.

An exploded view of one station, QA, with eight numbered parts: worker, trigger, inputs, tools, on pass, on fail, when blocked, and the retry limit that ends with a person.
  1. 1

    Worker

    An agent, person, crew, external runtime or another factory through an intake. Human approval can gate execution.

  2. 2

    Trigger

    A card dropped here, created here, or commented on here — any combination. Dropped is on by default, and it is what chains stations into a line.

  3. 3

    Inputs

    What the worker reads: the card’s fields and checklist, its discussion, the connected repository, and what the last station left behind.

  4. 4

    Tools

    Connected MCP tools and draft pull requests are both off until you allow this one station to use them.

ST-04 · WORKFLOW 01

QA

Running
1
Worker
Maya · QA Engineer
2
Trigger
on card drop
3
Inputs
card · comments · repository · previous output
4
Tools
granted at this station
5
On pass
→ Security
6
On fail
← Development
7
When blocked
→ Approval
8
Retries
3, then a person

Bay

CB-4128 · attempt 2 of 3

Refunds need a reason code

  1. 5

    On pass

    The next station — or another workflow in the factory. Arriving there starts the next worker.

  2. 6

    On fail

    Back to the station that can fix it, with the reason written into the card’s discussion.

  3. 7

    When blocked

    A worker that cannot verify something says so, and the card goes where you put a person.

  4. 8

    Retries

    How many times this card may come back before the loop stops and a person takes it.

Pass

The card moves to the next station, and arriving there starts the next worker.

Fail

The card goes back with the evidence in its discussion, so the next attempt starts from what actually happened.

Blocked

A worker that cannot verify something says so. When it is blocked, or the retries run out, a person takes it.

How routing works

05System Map

A System Map, not a code map.

CodeBook understands your system and uses that understanding to decide how work moves through the factory. Connect a repository and it is analysed — modules, services, API endpoints, data entities, outside systems, tests and patterns — with live progress, until the map reads SYSTEM MAP READY.

  • The code. Modules, services, API endpoints, data entities, outside systems, tests and patterns, derived by written rules — and a new map version on every push and merge.

  • The work. Factories, workflows, stations, workers, work orders, cards and pull requests, placed on the map by rule from the rows themselves.

  • The business. Company, products, requirements and decisions: written by your organization’s administrators, sent by a linked OpenBook space and MadeBook workspace, and linked to the code they concern.

  • The runtime. What is deployed, read from the repository’s deployment files, and production incidents and deploys from Sentry, Datadog, PagerDuty, Opsgenie, Grafana or a webhook — linked to the map by an administrator’s mapping or an exact name, never guessed. A production incident can raise the impact level of every card that touches it.

  • The docs. A Docs tab per repository, generated from the map and refreshed on push: overview, architecture, a page per service and module, API reference, data model and onboarding, every row cited. Export it as Markdown, or open it as a pull request.

Files
1,334
Modules
11
Services
2
API endpoints
33
Data entities
254
Outside systems
2
Tests
130
Status
SYSTEM MAP READY

For example: CodeBook’s own repository, analysed in production. Every count is read from the rows the analysis wrote; none is estimated.

Idea to App Factory · build workflow

Route by impact level

  • Low · Medium · HighDesign → Development → QA → Human review → Done
  • CriticalDesign → Architecture → Development → QA → Security review + Regression → Review gate → Human review → DoneA person approves each agent run
How the System Map worksImpact and risk routing

06Workforce

Hire from a roster of about 210.

Software, business and management teams, and 172 community skills with their authors credited. An installed agent belongs to your workspace, and its skill is plain text you can read, edit and reset.

Talk to any worker

Open a conversation with the agent on a station, with history you can pick back up. Ask the analyst for user stories and they appear on the line as cards.

See the marketplaceHow skills work

07Line catalogue

47 assembly lines to start from.

A template lays out the stations, installs its agents and wires the routes. Software is where CodeBook leads; the same factory model runs sales, finance, support and hiring, because the templates exist.

Software

12 lines

All 47 templates

08Repository

Engineers that open draft pull requests, and never merge.

Connect GitHub or GitLab to a workflow. Its engineering agents read the code, commit to a new branch and open a draft pull request linked to the card. Merging stays with you, under your own protection rules — and when the pull request is merged, the card moves.

  • Reading needs no grant. Any station’s worker can read the connected repository.

  • Writing is per station. Opening pull requests is off until you allow that one station.

  • Draft, never merged. An agent’s pull request is a proposal. A person decides what lands.

Repositories and pull requests
CB-4128 → draft pull requestGitHub · GitLab

  1. ST-03 Development

    A card arrives and the engineer starts

    Reading the connected repository needs no grant.

  2. New branch

    It commits to a branch of its own

    Only a station you allowed may write at all.

  3. Draft pull request

    It opens a draft, linked to the card

    A proposal. An agent never merges.

  4. A person

    Review and merge stay with you

    Under your own branch protection rules.

  5. Merged

    The merge moves the card

    Pull request state stays current on the card that produced it.

09MCP, both ways

Your workers use tools. Outside agents use your workflow.

The same protocol, in both directions — and the same rules apply whichever side the request comes from.

Tools come in to the workflow from a catalogue of 50 MCP servers, each off until switched on. Outside agents that speak MCP come in the other side and drive the workflow with a token scoped to it.

Tools in

Tool connections

A catalogue of 50 MCP servers. Every tool is off until you switch it on, and a station cannot use any of them until you allow that station.

  • Context7
  • DeepWiki
  • GitMCP
  • GitHub
  • Microsoft Learn
  • AWS Knowledge
  • Cloudflare Docs
  • Postman
  • Hugging Face
  • CircleCI
  • Buildkite
  • Semaphore
  • Cypress Cloud
  • Checkly
  • Currents
  • Sauce Labs
  • Datadog
  • Browserbase
  • Exa
  • Tavily
  • Firecrawl
  • Apify
  • Linear
  • Supabase
  • Neon
  • Stripe
  • Intercom

The workflow

Client on one side. Server on the other.

A move made over MCP obeys the same rules as a drag.

Agents in

The workflow is an MCP server

Anything that speaks MCP can read cards, move them and trigger a station’s worker, with a token scoped to that one workflow.

  • Claude Code
  • Codex
  • Kiro
  • Devin
  • · any MCP client

# file the card where the analyst will find it

create_card { column: "Backlog", title: "Refunds need a reason code" }

# and start the worker on that station

trigger_worker { card: "4128" }

How tool connections workHow the MCP server works

10Control and audit

Deterministic first.

The parts of a factory that have to be reliable are rules the platform enforces, not prompts an agent might follow.

  1. R-01

    Routing is a rule

    Where a card goes on pass, on fail and when blocked is configuration on the station. The agent reports an outcome; the platform makes the move.

  2. R-02

    Loops are bounded

    Every station has a retry limit. A card that has used it goes to a person instead of going round again.

  3. R-03

    Gates hold

    A human station, or an agent that runs only after approval, is enforced by the platform. No prompt talks its way past it.

  4. R-04

    Grants are per station

    Opening pull requests and using tool connections are both off until you allow them, station by station.

  5. R-05

    Handoffs follow declared routes

    An agent can only send a card to a workflow its station has a route to.

  6. R-06

    Every run is on the record

    Each step and each tool call is kept in the run’s audit trail, and the verdict is written on the card.

Run record · CB-4128 · ST-04 QAIllustration
  1. 09:14:02triggercard dropped from ST-03 Development
  2. 09:14:03startedskill + station instructions + card
  3. 09:14:21toolread repository · 4 files
  4. 09:15:07toolread draft pull request
  5. 09:15:40verdictFAIL — partial refunds lack a reason
  6. 09:15:40moved→ ST-03 Development · on fail

Accounts are your Bookbag account, shared across the suite. Run on managed models, or bring your own model keys.

Control and auditAll features

11Improve the factory

Change the process with a review trail.

Keep improving how work gets done: reuse a blueprint, review a proposed change, then promote it through your factory environments.

Keep your customizations

Preview a blueprint update, see what you and its publisher changed, and resolve conflicts before applying it.

Read the guide →

Review before publishing

Draft the edits, inspect their simulation, and ask another person to approve. Publish now or choose a later time.

Read the guide →

Promote one stage at a time

Compare Dev, Staging and Production factories. Move definitions forward while cards and run history stay with each factory.

Read the guide →

Start with Test factory and versions. Check implementation status for current limits.

12Context and learning

Give workers context. Test what they learn.

Bring the decisions behind the work into the factory, then review how new instructions change an agent’s output.

Answers with sources

Add product documents, selected code files and GitHub conversations. Workers retrieve permitted passages with citations, and required context can block a run when it is missing or stale.

Connect knowledge →

Instructions you can reuse

Build workspace skill packages with fixed versions, dependencies and conflict checks. Preview the combined instructions before applying them to a worker.

Compose reusable skills →

Evaluate before release

Turn a reviewed lesson into a candidate. Compare text-evaluation results, choose a rollout percentage and restore a prior version when needed.

Explore agent studio →

Capacity shared across factories

Set a shared limit for running and external jobs. Queued work waits for capacity, while factory policies and budgets keep applying.

Set capacity limits →

For external workers, use the TypeScript and Python SDKs. See current limits and verification status before relying on a deployment.

13Run it under governance

Run it for real: governed, supervised, locked down.

What shipped this weekend — every one of these is a rule the platform enforces, and each page says what is not built yet.

Linked to MadeBook and OpenBook

Stories from OpenBook become cards. Each AI run is a governed MadeBook session that obeys its decisions and stops. Status and evidence go back through a signed, retryable outbox.

How linked products work →

Supervisors above every workflow

A specialist per failure class and a factory supervisor with a closed list of options — reroute, reassign, pause, replan the rest, escalate. Past a bound, a person is asked with no model call.

Read about supervision →

Credential leases and one outbound door

A run holds a two-minute lease, not a stored credential. Every request it can cause passes an egress policy, and agent pull requests get a dependency gate against OSV.dev.

See the security infrastructure →

Model policies with fallback chains

Pin a model, name a chain of up to four, or let CodeBook choose from measured quality, speed or tokens — per factory, station or worker, among the models SSO already offers.

Set a model policy →

Six more runtimes

GitLab CI/CD, CircleCI, Buildkite, Cursor, Jules and GitHub Copilot work a station over their own APIs, with every vendor state mapped explicitly.

Connect a runtime →

Managed service mode

A customer grants a provider read or operate access, revocable by either side and audited, with a provider console, per-customer SLA reports and white-label branding.

Operate for customers →

Knowledge now also reaches pull-request reviews, approved web pages, and Jira, Linear, Slack and Notion, and the repository graph reads Go, Java, Rust and PHP beside JavaScript, TypeScript and Python. What has and has not run for real is on implementation status.

14On the line next

On the line next.

These capabilities are unfinished. They are listed separately so you can plan around what the product supports now.

Not complete · These areas still need implementation or end-to-end verification. Each entry explains what exists and what remains.

  1. N-01Verification pending

    Canary execution

    Durable per-run settings and start, stop, comparison and promotion controls are implemented. Local two-person approval, candidate outcomes and stopping passed with a scripted model; production promotion and real-provider validation remain.

  2. N-02Planned

    Unified factory data plane

    Planned work connects existing memory, knowledge, skills and evidence through shared retrieval, provenance, reviewed improvement proposals and more complete factory versioning.

Ready to run

Don’t build your own software factory. Assemble one.

Build the factory. Pick the workers. Define how work moves. CodeBook runs it.

Get startedSee how it works

Sign in with your Bookbag account