Everything a software factory is made of.

Factories

A factory holds as many workflows as a team needs, side by side on one floor.

Stations with a worker

Assign a station to an agent, person, crew, external runtime or another factory through an intake. Human approval can gate execution.

Workflow templates

Templates lay out stations, install agents and wire routes. Connect a model and the tools the work needs before starting runs.

Factory blueprints

A whole factory — every workflow, its workers, the routes between workflows, gates, contracts, supervisors, policy and memory — installed in one step, published for your organization, or exported to a file. Fourteen are built in, including one that turns a sentence into epics, stories and draft pull requests.

Factory versions and rollback

A version is recorded whenever the factory's definition changes, every run records the version it ran under, and any version can be compared in plain sentences or rolled back to without touching cards or history.

Test factory

Walk the factory's rules with scripted outcomes before real work does — no model, no tokens, nothing written — and get a readiness report: routing, failure paths, escalation, permissions, cost control, contracts.

Blueprint updates and workspace copies

Preview publisher changes alongside your customizations, resolve conflicts, check compatibility and apply an update as a factory version. Copy a published blueprint into your workspace to develop it independently.

Factory environments

Arrange factories into an ordered environment chain. Compare and promote definitions one stage at a time, with optional second-person approval in the destination.

Factory setup checklist

Ten steps on Overview read the current factory configuration and work history, explain what is missing and link to the right setting. Six required steps determine completion; opening the list makes no model call.

Factories as files

Export supported factory settings, agent instructions and scorers as a zip; preview updates or create a factory from the file. Credentials and run history stay out; complete environment reproduction remains future work.

The marketplace

Software, business and management teams plus community skills with author credit, installed per workspace.

Editable skills

An agent’s skill is plain text you can read, edit and reset to the original.

Talk to any worker

Conversations with history. Ask the analyst for stories and they appear on the line as cards.

External runtimes as workers

A station can be worked outside CodeBook: by any MCP agent — Claude Code, Codex, Kiro, Amp — that pulls work with the workflow's token, by a signed webhook, by a GitHub Actions workflow, by a Devin session, or through a dedicated adapter for GitLab CI/CD, CircleCI, Buildkite, Cursor, Jules and GitHub Copilot. CodeBook sends the brief, waits, and routes pass, fail or blocked as it does for its own agents.

Worker performance and best-worker routing

First-pass rate, tokens, duration and reopen rate per worker and per station, with minimum samples. A station can share its cards between several workers — CodeBook's agents and outside runtimes — and route each one to whoever has the best record there. Arithmetic, not a model.

Dynamic worker routing

A station can share its cards between several workers and route each one by first-pass quality, tokens, speed, current workload or clearance — including “best quality under N tokens”, fallback chains when a worker fails, and A/B tests between two workers. Arithmetic over real runs; no model picks a worker.

Worker reputation from real outcomes

Reverts, production issues, human overrides and reopen rates per worker, by kind of work, by repository and over time. Numbers with their samples, from your own workspaces — never stars.

Permissions by worker

Repository access, tool connections, creating cards, handoffs and memory proposals, set per worker on top of factory policy and station switches. A tool that is not allowed is never offered to the model, and nothing a model can call touches permissions.

Crews as workers

A leader, member agents and a reviewer work a station together, with bounded tasks, permissions and token budgets.

Reusable skill packages

Compose worker instructions from immutable workspace packages, exact dependency versions and checked conflicts. Preview the result and roll back explicitly.

Agent evaluations and releases

Compare instruction versions against frozen text and tool-fixture datasets, gate candidates on passing results and select a rollout percentage for station execution and supported outside-worker briefs. Manager chat and supervision still use live instructions.

Human-reviewed learning

Turn worker memory proposals into inactive instruction candidates with reviewer provenance. Evaluate and release them deliberately; reviewing a lesson does not activate it.

Dedicated runtime adapters

GitLab CI/CD, CircleCI, Buildkite, Cursor, Jules and GitHub Copilot work a station over their own APIs, with typed settings, a credential test, every vendor state mapped explicitly, a deadline and vendor-side cancellation where one is documented.

Manager model and agent settings

Open Manager settings from the board to choose the installed manager’s model policy, inspect permissions and open its instructions or Studio. The model policy governs both conversations and automatic interventions.

Agent version and model replay matrix

Compare original task measurements with version/model evaluations on frozen cases, including pass rate, usage, cost, latency, tool failures and stale dataset revisions. Queue a matrix without touching production tools.

Card-driven triggers

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

Pass, fail, blocked

Each station says where a card goes on pass, on fail and when blocked, with bounded retries and escalation to a person.

Workflows hand work to each other

Move, send, or send and wait — with a typed brief of goal, evidence and open questions, along declared routes only, loops bounded.

Human gates

A station a person holds, or an agent that runs only after a person approves.

Parallel branches with join gates

A passing station fans a card out to several stations at once. The card waits at a gate that counts the results — no model involved — and goes on only when every branch has passed; one failure sends it back with every finding attached.

Artifacts and station contracts

Stations produce typed artifacts — requirements, a pull request, a test report, a security report — and a station's contract says what a card must have before work starts there and what it must have gained to pass. Enforced by the platform for workers.

Work orders and the planner

A goal bigger than one card, with progress, active runs, blocked work and tokens rolled up across every workflow. A planner agent proposes the work items; a person turns them into cards. The planner decomposes work; the supervisor watches it.

Dependencies, templates and an executive report

Work items with dependencies, pause and resume, cancellation, reusable templates, risk reasons, a critical path and a printable report. The planner proposes work for a person to review.

Factories working for factories

Send work through an explicit intake into another factory, follow the linked work, and receive its result under bounded cross-factory rules.

Risk-adaptive routing

A station's routes, handoffs and parallel branches can carry an impact level and apply only to cards at that level while the factory's policy switches risk routing on, and a policy level from which a person approves runs. In the Idea to App Factory a critical story is architected first and fans out to Security review and Regression; every other story takes the default path. Part of the versioned definition; Test factory walks each level; a model picks neither.

Repositories and draft pull requests

GitHub, GitLab, a self-hosted Gitea, or a git host inside CodeBook that needs no account. Start a new repository from the workflow; agents read the code and open draft pull requests, never merge; a merged pull request moves its card.

Tool connections over MCP

A catalogue of MCP servers. Every tool is off until switched on, and each station needs its own permission.

The workflow is an MCP server

Outside agents can read cards, move them and trigger a station’s worker with a token scoped to one workflow.

Event bus

Every move, run, gate, handoff and version change published as signed events to your systems, and inbound triggers that let monitoring open an incident at a station or report that finished work broke production.

Knowledge with citations

Give workers scoped documents, selected GitHub files, issues, discussions, pull requests with their reviews, pages on approved web origins, and Jira, Linear, Slack and Notion items. Retrieve relevant passages with source citations, freshness requirements and explicit external-worker access.

Source-backed domain relationships

Connect services, teams, APIs, databases, incidents and decisions to cited evidence. Changed source text makes records stale until reviewed, and hidden sources stay hidden from graph traversal.

Selected-file code graph

Inspect static declarations and imports in JavaScript, TypeScript, Python, Go, Java, Rust and PHP files with file and line citations, module roots from declared configuration, dynamic imports marked as possible, and framework routes — filtered by the same source permissions as retrieval. C# and Ruby are not supported.

TypeScript and Python worker SDKs

Use source-installable lifecycle clients to claim work, report progress, attach artifacts and complete jobs through workflow MCP tokens, and a deployed-factory check that walks the whole lifecycle and ends with a person deciding.

Knowledge from Jira, Linear, Slack, Notion and the web

Index a pull request with its reviews, a page on an administrator-approved web origin, or a Jira, Linear, Slack or Notion item as a scoped source. Token authentication, exact-host approvals, no crawling; limits fail rather than truncate.

Linked MadeBook and OpenBook workspaces

Link a workspace so stories from OpenBook become cards and epics become work orders whose planned stories wait for a person, each AI run is a governed MadeBook session that obeys its decisions and stops, and status and evidence go back to OpenBook through a signed, idempotent, retryable outbox. Peers and the shared secret come from Bookbag SSO.

Runner recordings and files

Keep browser recordings, logs and reports in SSO storage with authenticated access, and play recordings beside a card’s evidence. File type, size, count and runner ownership are checked.

System Map

Connecting a repository analyses its tree into typed modules, services, endpoints, data entities, external systems, queues, tests and patterns over the static code graph, with progress read from real rows, a map that is ready or says why it is limited, incremental updates on push and merge, a version per commit, five list views and a node sheet with citations, organization nodes written by administrators and factory objects placed by rule.

Ranked, recorded context pack

For a workflow with a mapped repository, one context pack per run from the card's seeds, a two-hop walk of the map, cited retrieval and the seed files' code, scored by a written rule inside the existing budget, with K/N/E citations and every candidate — included or omitted — recorded on the run. An optional model re-rank may only reorder what the rule found.

Production monitoring

Runtime nodes read from the repository's deployment descriptors, and incidents and deploys from Sentry, Datadog, PagerDuty, Opsgenie, Grafana / Alertmanager or a generic webhook, each source with its own address and a token shown once. Incidents are linked to runtimes, services and modules by an administrator's mapping or an exact name — never guessed — deploys record the commit a runtime is running, and production incidents count toward a card's impact level.

Generated docs from the System Map

A Docs tab per repository — overview, architecture, a page per service and module, API reference, data model, onboarding and glossary — generated from the map with every row cited, refreshed on push with unchanged pages carried, model prose only from listed facts, Markdown export, a pull request an administrator opens, and D citations that agents and Ask read.

Very large repositories

No file cap on a System Map build: measured end to end at 200,000 and 250,000 files, with batched reads, a request budget that grows with the repository, default excludes you can override, monorepo packages with a picker, one build per organization at a time, waits for the host's rate limit, and progress with a labelled time estimate.

Deterministic-first control

Routing, retry limits, gates and grants are rules the platform enforces, not prompts.

Audit trail

Every run keeps each step and each tool call, and writes its verdict on the card.

Factory overview

Every workflow in the factory with what is running, waiting and blocked, and the traffic between workflows.

A supervisor for exceptions

Each workflow can have a supervisor agent, asked only when the rules run out: blocked with nowhere to go, a run that cannot start, a refused handoff. It picks from a fixed list, is bounded per piece of work, never overrules the retry limit, and logs every decision. Past its limit a person is asked.

Scoped memory

What workers are told, layered organization → workspace → factory → workflow → worker. An agent can propose a note; nothing it proposes is in force until a person approves it.

Enforced policies and budgets

Token budgets per card and per day, run caps, concurrency limits, and switches for pull requests, tools, outside runtimes and handoffs. Enforced by the platform: a tool that is off is never offered to the model, and a spent budget is a call that is not made.

Factory metrics

Throughput, cycle time, working versus waiting time per station, tokens per card, and bottleneck detection in plain words.

Factory map and runs

The work graph drawn as a factory floor — parallel lanes, join gates, fail-back loops, routes to other workflows, live counts on every station — and every run of a workflow in one list.

Factory outcomes

What became of finished work — merged, reverted, reopened, redone by a person, flagged by production — scored per factory version, so “v18 is better than v17” is a measurement. Recent work stays provisional until enough time has passed to know.

Operations center, pause and kill switch

Everything running, waiting on a person, blocked or out with a runtime, with token burn and alerts from a dozen health checks. Pause the factory, pause one runtime, stop everything, or revoke what every worker may touch — and restore it exactly.

Autonomy levels

Observe, suggest, execute with approval, execute low-risk work, fully autonomous — set per factory, per station and per worker; the lowest wins. It can step down by itself after a bad outcome. Only a person raises it.

Factory optimization engine

CodeBook reads how the factory actually ran and recommends changes with their evidence: parallelise two reviews, add a review where work keeps bouncing, route to the worker who does the same job for fewer tokens, drop an approval that never says no. Each is tested against Test factory and applied by a person in one click, as a new version you can roll back.

Live map and hotspots

See workflow paths and overlays for utilization, failures and waiting work. Use them to locate a bottleneck, then inspect the affected cards and runs.

Reviewed and scheduled changes

Draft named edits, inspect the diff and simulation, request a second person’s review, then publish now or schedule publication. Keep the decision history with the change.

Independent evaluators

Judge a worker’s pass using another agent, pull-request checks, output rules or human sampling. Required evaluations combine under an explicit rule; unavailable evaluations do not silently disappear.

Shared factory capacity

Assign factories to a workspace pool that limits running and external jobs together. New work waits for a slot while existing work finishes.

Factory and specialist supervisors

A specialist per failure class, a factory supervisor above every workflow with a closed list of options — reroute, reassign, pause, replan the rest, escalate — one supervisor per piece of work at a time, and bounds per piece and per work order. Past a bound a person is asked with no model call.

Credential leases, egress policy and scanning

A run holds a two-minute lease bound to its job and one host instead of a stored credential. Every request a run can cause goes through one outbound door with private-network refusal and a per-factory allowlist. Uploads and artifacts are sniffed and scanned, and agent pull requests get a dependency gate against OSV.dev.

Model policies and fallback chains

Pin a model, name a fallback chain of up to four, or choose from measured station quality, speed or tokens. Policies apply to station runs, conversations and workflow, specialist and factory supervision; planner, evaluator and crew policy integration remains open.

Governance handoff to MadeBook

In a workspace linked to MadeBook, every model a governed run uses is checked with MadeBook before the call, every way a session ends is reported, CodeBook’s contract and evaluator results go to MadeBook as reported evidence, governance events reach its sealed audit trail, and run bodies are kept only as long as the organization’s retention allows.

Managed service mode

A customer grants a provider organization read or operate access, revocable by either side and audited. The provider console covers every granted factory, with per-customer SLA targets and CSV reports and white-label branding.

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.

Historical workflow replay

Replay recorded workflow versions and visits within the last 30 days, with a time scrubber and range playback. Missing history is reported rather than reconstructed from guesses.

Scorers with change evidence and human review

Sample station results with twelve ready-made questions or your own, target workflows, agents and files, prioritize real pull-request evidence, and track not-scored reasons, coverage and human agreement. Scorers never block work.

Reviewed factory improvement

Require enough undisputed failure evidence before the observer proposes an instruction or factory change. Test inactive instruction candidates before release and measure improvement, regression and release against matching evaluation baselines.

Trust scorecard and targets

Track ten reliability measures with sample sizes, prior-window comparisons and targets saved by a person. Too little data never counts as meeting a target; targets do not change policy.

Measured AI spending

Translate recorded usage into dollars using model prices configured at SSO, retaining token-kind detail where supplied. Separate run and judging costs, and show unpriced usage explicitly.

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.

System impact and blast radius

Cards and work-order lines get LOW, MEDIUM, HIGH or CRITICAL from written thresholds over counted dependents, endpoints, data, personal data, outside systems, tests and incidents, with the reasons, the nodes and the projected route on the card, an override a person makes with a reason, and impact.computed events.

Ask your system

A read-only chat on the System Map pages with eight lookup tools, answers that cite nodes, edges, knowledge passages and generated docs, a platform-written refusal when the tools find nothing, impact levels by the same rule as impact analysis, and the same row-level permissions as the pages. Nothing it can call writes.

Work snapshots

Card creation, a plan turned into cards, an accepted story and every run start record the factory version, each repository's map version and every permitted source's content hash, shown as one line on work orders and runs and reconstructable to the definition, the map at that version and what the model actually read.

Context engine measurement

Every run records the context it was sent, an estimate of what the pre-engine path would have sent, labelled as an estimate, and the tokens the provider reported. A factory can hold out a share of its cards on the pre-engine path and compare tokens, first pass, rework, human rejection, time to done and citations under a written significance rule, in Factory metrics and as a CSV. Nothing is switched automatically.