# CodeBook > CodeBook is the software factory builder. Don’t build your own software factory. Assemble one. Build the factory. Pick the workers. Define how work moves. CodeBook runs it. CodeBook is the software factory builder. Coding agents are getting good at manufacturing software; the factory around them — queues, pipelines, scheduling, supervision, governance, permissions, audit — is usually left for each team to build. CodeBook is that factory, ready to assemble: lay out assembly lines as boards whose columns are stations, put a worker on each one — an agent from the marketplace, a person, or an agent gated by a person’s approval — and define how work moves. Pass, fail and blocked route every card, with bounded retries and escalation to a person. How it works, in one sentence: a board where the columns have workers. Software is the lead use case — features, bugs, incidents, security, migrations. The same factory model runs sales, finance, support and hiring, because the templates exist. ## The argument Coding agents and agent crews are getting good at manufacturing software. Every team is then told to build the factory around them: memory, scheduling, queues, pipelines, supervision, governance, permissions, audit, multi-agent coordination. CodeBook is that factory, ready to assemble. Outside agents (Claude Code, Codex, Kiro, Devin and any other MCP client) can work inside it by driving a workflow over MCP. ## Vocabulary - Factory = the floor. The operating environment for one team. It holds every line that team runs. - Workflow = assembly line. A board. Build as many as the team needs. - Station = a column. One job, one worker, one definition of done. - Worker = who does the job. An agent, person, crew, external runtime, or another factory through an intake. - Card = work item. The whole brief: fields, checklist, attachments, discussion. - Move = handoff. A card arriving at a station starts its worker. - Gate = quality control. Pass, fail or blocked — and a person where it matters. - Marketplace = workforce. Where you hire the agents that staff the stations. ## Implemented capabilities Deployment and integration setup still require verification. Consult the implementation-status documentation for unfinished work and current limits. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - Crews as workers: A leader, member agents and a reviewer work a station together, with bounded tasks, permissions and token budgets. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 47 workflow templates in 9 categories (Start a business, Run a business, Sales, Marketing, Customers, Finance, People, Product, Software). - A marketplace of 212 agents: 40 written by CodeBook (software, business and management teams) and 172 community skills with author credit. - A catalogue of 50 MCP tool servers; every tool is off until switched on. - Accounts and AI run through a Bookbag account; use managed models or bring your own model keys. ## On the line next (not complete) These areas need implementation or end-to-end verification. Preserve the limits in each entry; do not describe them as complete. - Canary execution (not complete): 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. - Unified factory data plane (not complete): Planned work connects existing memory, knowledge, skills and evidence through shared retrieval, provenance, reviewed improvement proposals and more complete factory versioning. ## Pages - [Home](https://codebook.work/): assemble your software factory — the argument, the floor plan, a station taken apart - [How it works](https://codebook.work/product): vocabulary, structure, the anatomy of a station, handoffs between workflows - [Workforce](https://codebook.work/agents): the agent marketplace - [Assembly line templates](https://codebook.work/workflows): every template, station by station - [Features](https://codebook.work/features): the bill of materials — every part, live or next - [About](https://codebook.work/about) ## Features - [Factories](https://codebook.work/features/factories): A factory is the operating environment for one team or function. Inside it you build as many workflows as that team needs — feature development, bug fixes, incidents, security remediation — and they share the same workers, tools and rules. - [Workers on stations](https://codebook.work/features/workers-on-columns): Every column in a workflow can have one worker behind it — an agent you hired, a person, or an agent that waits for a person’s approval. The column stops being a place cards wait and becomes a station where something happens to them. - [Triggers](https://codebook.work/features/triggers): A card dropped into the station, a card created there, a comment left on one. Each is a switch you turn on per station, so work starts when it is ready rather than when somebody remembers. - [Pass, fail, blocked](https://codebook.work/features/handoffs): A station names where a card goes when its worker passes, where it goes when the worker fails, and where it goes when the work is blocked or the retries run out. Those are rules the system enforces, not prompts — and they are enough to build a delivery loop that closes. - [Workflows that hand off to each other](https://codebook.work/features/workflow-handoffs): A station can route a card to another workflow in the same factory: move it there, send a linked copy and carry on, or send it and wait for it to come back. Every handoff carries a typed brief, and agents can only hand off along routes you declared. - [Workflow templates](https://codebook.work/features/templates): 46 workflow templates in 9 categories. A template lays out the stations, installs the agents it needs into your workspace and puts each one on its station, with pass and fail routes already wired. - [The agent marketplace](https://codebook.work/features/agent-marketplace): Software, business and management teams CodeBook wrote, plus community skills with their authors credited. Install one and it belongs to your workspace, with a skill you can read, edit and reset. - [Skills](https://codebook.work/features/skills): A skill is plain text you can read. No hidden prompt, no black box — what the agent was told is on the page, and you can change it. - [Talk to the worker](https://codebook.work/features/chat): Click the agent on any station and talk to it. Ask the analyst for user stories and they appear in the workflow as cards. Start a new session or pick up an old one — and what you said stays yours. - [The discussion](https://codebook.work/features/comments): A GitHub-shaped thread on every card: humans, agents, verdicts, evidence and questions in one place, in order. - [Card templates](https://codebook.work/features/card-templates): Build the card yourself: the fields, the checklists, the attachments. Everything on it goes to the worker that picks it up. - [The board](https://codebook.work/features/board): Groups, columns, drag and drop, labels, a filter builder with saved filters, a list view and scheduled cards. A workflow is a board first, which is why it is instantly understandable. - [Workspaces](https://codebook.work/features/workspaces): An organization holds workspaces, a workspace holds factories, and a factory holds workflows. Membership and roles come from your Bookbag organization. - [Repositories and pull requests](https://codebook.work/features/repositories): Connect GitHub, GitLab, a self-hosted Gitea or the git host inside CodeBook to a workflow and its engineering agents read the code, make the change on a branch and open a draft pull request — never a merge. When the pull request is merged, the card moves. - [Tool connections](https://codebook.work/features/tool-connections): A catalogue of MCP servers — live documentation, web search, GitHub, Linear, Stripe, Supabase and more. Every tool is off until you switch it on, and a station cannot use any of them until you allow that station. - [The workflow as an MCP server](https://codebook.work/features/mcp): Every workflow’s board is also an MCP server, so outside agents — Claude Code, Codex, Kiro, Devin, anything that speaks MCP — can read cards, move them and trigger the worker on a station. - [Notifications](https://codebook.work/features/notifications): A station can email somebody when work arrives — the reviewer who needs to look, the person whose answer the agent is waiting on. - [Human approval](https://codebook.work/features/approvals): Put a person on a station and the work waits there. Approve it and it moves on; reject it and it goes back with your reasons. The gate is enforced by the system — no prompt can talk its way past it. - [Platform administration](https://codebook.work/features/platform-admin): Platform administrators maintain the agents everyone installs: create them, write their skills, edit them, reset them to the shipped version and retire them. - [One Bookbag account](https://codebook.work/features/accounts): CodeBook has no password of its own. It is an OpenID Connect client of the Bookbag account service, which is also where organizations and people are managed. - [Control and audit](https://codebook.work/features/privacy): Pass/fail routing, retry limits and human gates are rules the system enforces, not prompts. Every run keeps an audit trail of each step and tool call, and an agent’s reach is the grant you gave its station. ## Documentation ### Getting started - [What is CodeBook?](https://codebook.work/docs/getting-started/what-is-codebook): A software factory builder — factories that hold workflows, workflows whose columns are stations, and a worker on every station. - [Create your workspace](https://codebook.work/docs/getting-started/create-your-workspace): Sign in with your Bookbag account, pick an organization, and make the workspace and the factory your workflows will live in. - [Finding your way around](https://codebook.work/docs/getting-started/finding-your-way): Where signing in lands you, what the organization home and the sidebar hold, the two switchers, search, and which organization pages now live at Bookbag SSO. - [Your first workflow](https://codebook.work/docs/getting-started/your-first-workflow): Add a workflow to your factory from a template or build its stations by hand, and understand what a card has to carry before a worker can use it. - [Install your first agent](https://codebook.work/docs/getting-started/install-your-first-agent): Open the marketplace — your factory's workforce — hire a specialist, and understand what installing actually copies. - [Staff your first station](https://codebook.work/docs/getting-started/staff-your-first-station): A station's settings, tab by tab — the worker, the triggers, where the card goes next, permissions and runs. - [The factory setup checklist](https://codebook.work/docs/getting-started/factory-checklist): See what your factory has configured, what is missing, and where to finish each setup step. ### Operating your factory - [Blueprint updates and workspace copies](https://codebook.work/docs/factory/blueprints): Install a factory definition, preserve your customizations during updates, and make an independent workspace copy. - [Review and schedule factory changes](https://codebook.work/docs/factory/changes): Draft named edits, inspect their impact, request an independent review and publish now or later. - [Factory environments and promotion](https://codebook.work/docs/factory/environments): Arrange factories into stages, compare their definitions and promote changes with destination approvals. - [Test factory, versions and rollback](https://codebook.work/docs/factory/versions-and-testing): Check routing and configuration before execution, compare definitions and restore a previous version. - [Optimization and measured outcomes](https://codebook.work/docs/factory/optimization-and-outcomes): Use run evidence to identify bottlenecks, review recommendations and compare factory versions. - [Policies, operations and the factory map](https://codebook.work/docs/factory/policies-and-operations): Set token and concurrency limits, inspect active work and control how much workers may do. - [Scoped memory and proposals](https://codebook.work/docs/factory/memory): Give workers persistent guidance at the right scope and review what they propose to remember. - [Knowledge sources and citations](https://codebook.work/docs/factory/knowledge): Give workers scoped documents, selected repository files, repository conversations, pull-request reviews, approved web pages and ticket-system items, with access controls, freshness requirements and cited retrieval. - [Knowledge from pull requests, the web, and ticket systems](https://codebook.work/docs/factory/knowledge-connectors): Index a pull request with its reviews, a page on an approved web origin, or an item from Jira, Linear, Slack or Notion as a scoped knowledge source. - [System Map](https://codebook.work/docs/factory/system-map): What CodeBook knows about the system behind your repositories and the work that touches it — five list views, an Ask tab and a Docs tab, a node sheet with citations, the analysis that runs when a repository is connected, runtime nodes and production incidents, incremental updates on push and merge, very large repositories and monorepos, and what the map does not claim. - [Generated docs](https://codebook.work/docs/factory/system-map-docs): The Docs tab of a repository on the System Map — documentation generated from the map, refreshed on push, cited row by row, exported as Markdown or opened as a pull request, and read by agents and Ask with D citations. - [The factory dashboard](https://codebook.work/docs/factory/dashboard): Inspect productivity, spending, scorer evidence, Trust targets and improvement results over the current and previous windows. - [Scorers and self-improvement](https://codebook.work/docs/factory/scorers-and-self-improvement): Judge real change evidence, review the judge, measure coverage, and evaluate proposed improvements before releasing them. - [Benchmarks](https://codebook.work/docs/factory/benchmarks): Replay a set of the factory's own finished tasks on other models, grade every answer with the factory's scorers, and compare cost against quality. - [The factory as files](https://codebook.work/docs/factory/files): Export supported factory settings and agent instructions as a zip, inspect changes before updating, or create a factory from the file. - [Trust targets and reliability](https://codebook.work/docs/factory/trust): Measure ten factory outcomes against targets you choose, with sample sizes and a comparison to the previous window. ### Agents - [The marketplace](https://codebook.work/docs/agents/the-marketplace): Your factory's workforce — software, business and management teams and 172 community skills — and how installing, editing, resetting and deactivating work. - [Skills](https://codebook.work/docs/agents/skills): What a skill is, what every shipped skill says, and which lines you should think twice about before editing. - [Editing and resetting](https://codebook.work/docs/agents/editing-and-resetting): How your copy of a skill changes, what revision means, and exactly what Reset skill restores. - [Writing your own agent](https://codebook.work/docs/agents/writing-your-own): How to write a skill from nothing that produces work you can rely on, with a template to start from. - [Conversations](https://codebook.work/docs/agents/conversations): Talking to the worker on a station, asking it to write cards, sessions, and why nobody else can read yours. - [Crews as station workers](https://codebook.work/docs/agents/crews): Coordinate a leader, member agents and a reviewer behind one station. - [Reusable workspace skills](https://codebook.work/docs/agents/reusable-skills): Publish immutable instruction packages, pin dependencies and compose a worker from explicit versions. - [Routing, fallbacks and worker performance](https://codebook.work/docs/agents/routing-and-performance): Choose workers using recorded outcomes, token usage, speed, workload and eligibility. - [Agent studio](https://codebook.work/docs/agents/studio): Version instructions, evaluate frozen datasets through SSO, compare results and control production rollout. - [Compare versions and models with replay](https://codebook.work/docs/agents/replay): Compare historical tasks with agent-version and model combinations using frozen evaluation cases, recorded usage and explicit baselines. ### Workflows & stations - [Workflows and stations](https://codebook.work/docs/workflows/stations): What a workflow is, everything a station carries, why one worker per station is the rule, and how to divide work into stations that hold. - [Triggers](https://codebook.work/docs/workflows/triggers): Dropped or created — what each trigger does, why comments never start work, how duplicate events are handled, and how to start a run deliberately. - [Pass, fail and retries](https://codebook.work/docs/workflows/handoffs-and-retries): Where a card goes when the work passes, fails or is blocked, what the retry limit is for, and how to design a loop that closes. - [Handoffs between workflows](https://codebook.work/docs/workflows/handoffs-between-workflows): Routing a card to another workflow in the same factory — move, send, or send and wait — the typed brief it carries, and what keeps it bounded. - [Approvals and people](https://codebook.work/docs/workflows/approvals-and-people): Human stations, the agent-after-approval worker type, and where to put a person so the line still holds. - [Notifications](https://codebook.work/docs/workflows/notifications): Per-station email on arrival, the shared Bookbag inbox, and mentions in the discussion. - [Workflow templates](https://codebook.work/docs/workflows/templates): The 46 workflow templates in 9 categories, what a template sets up, and the rule that stops one overwriting your work. - [Workflow managers](https://codebook.work/docs/workflows/managers): Talk to the workflow manager, configure its model and permissions, and understand what it can do when work needs help. - [Artifacts, contracts and evaluators](https://codebook.work/docs/workflows/contracts-and-evaluators): Define the evidence a station needs and independently judge a worker’s pass. - [Work orders and planning](https://codebook.work/docs/workflows/work-orders): Track a goal across dependent work items and multiple workflows. - [One factory working for another](https://codebook.work/docs/workflows/recursive-factories): Use explicit intakes to pass bounded work into another factory and receive its result. - [Factory supervision](https://codebook.work/docs/workflows/supervision): Specialist supervisors per failure class, a factory supervisor above every workflow, one supervisor per piece of work at a time, and replanning the unmet rest of a work order. - [System impact and risk routing](https://codebook.work/docs/workflows/system-impact-and-risk-routing): How a card gets a blast radius — LOW, MEDIUM, HIGH or CRITICAL, with the reasons — from the System Map, how a person overrides it, and how a station's routes can depend on the level so critical work takes a longer path through the factory. ### Cards & the board - [Cards and card templates](https://codebook.work/docs/board/cards-and-templates): Designing the card so the worker gets a brief rather than a title — fields, checklists, attachments and reusable templates. - [Discussion](https://codebook.work/docs/board/discussion): The thread on every card — where questions, verdicts and evidence live, and how to bring an agent into it. - [Groups, filters and views](https://codebook.work/docs/board/groups-filters-and-views): The ordinary board features under every workflow — groups, labels, the filter builder, the list view and the personal task list. - [What the worker reads](https://codebook.work/docs/board/what-the-worker-reads): Exactly what is sent to a model when a run starts, and what is not. - [Measuring the context engine](https://codebook.work/docs/board/measuring-the-context-engine): What CodeBook records about the context each run was sent, the estimated pre-engine baseline beside it, the provider's actual tokens, and the optional per-factory holdout that compares outcomes with a written significance rule — in Factory metrics and as a CSV. - [Ask your system](https://codebook.work/docs/board/ask-your-system): A read-only chat over the System Map — what it can answer, how every answer cites the nodes it stands on, and why it says the map has nothing rather than guess. ### Integrations - [Repositories](https://codebook.work/docs/integrations/repositories): Connecting GitHub, GitLab or a self-hosted Gitea to a workflow, the System Map analysis and its limits on very large repositories, the push webhook CodeBook registers and repairs, creating a repository, and why opening pull requests is a per-station grant. - [Pull requests](https://codebook.work/docs/integrations/pull-requests): Draft pull requests linked to the card that produced them, what agents are told about conflicts, who merges, and how a merge moves the card. - [Tool connections](https://codebook.work/docs/integrations/tool-connections): Connecting MCP servers so your workers have tools — the catalogue, the two switches between a tool and a run, and what cannot be connected yet. - [The MCP server](https://codebook.work/docs/integrations/mcp-server): Every workflow is also an MCP server, so outside agents can read cards, move them and trigger workers — the tools it offers, how tokens are scoped, and what a token can never do. - [External worker runtimes](https://codebook.work/docs/integrations/external-runtimes): Run a station through MCP pull, signed webhooks, GitHub Actions, Devin, or a dedicated adapter for GitLab CI/CD, CircleCI, Buildkite, Cursor, Jules or Copilot. - [Command runners](https://codebook.work/docs/integrations/command-runner): Run your repository's own commands — tests, lint, build — on a machine you own, so agents can ask for them by name. The application server does not execute repository code. - [Dedicated runtime adapters](https://codebook.work/docs/integrations/runtime-adapters): Work a station through GitLab CI/CD, CircleCI, Buildkite, Cursor, Jules or GitHub Copilot with the vendor's own API, a credential you create and explicit state mapping. - [Worker SDKs](https://codebook.work/docs/integrations/worker-sdk): Build an external CodeBook worker in TypeScript or Python with a workflow-scoped token. - [Events and outcome reporting](https://codebook.work/docs/integrations/events): Connect signed outbound events and inbound triggers to systems outside CodeBook. - [Production monitoring](https://codebook.work/docs/integrations/production-monitoring): Connect Sentry, Datadog, PagerDuty, Opsgenie, Grafana / Alertmanager or a generic webhook to the System Map — the address and headers each source uses, how incidents are linked to runtimes, services and modules, the mapping table, deploy events, and where production incidents change what CodeBook does. - [Linked products — MadeBook and OpenBook](https://codebook.work/docs/integrations/linked-products): Link a workspace to MadeBook and OpenBook, run work under MadeBook governance, receive stories and epics from OpenBook and report back, and see which parts of the lifecycle have run for real. - [The governance handoff to MadeBook](https://codebook.work/docs/integrations/governance-handoff): In a workspace linked to MadeBook, MadeBook holds the rules and the record and CodeBook enforces its answers — models asked before use, sessions ended, evidence reported, one audit trail and retention of run bodies. ### Administration - [Platform administration](https://codebook.work/docs/administration/platform-admin): Who can reach the admin area, and how the marketplace catalogue is created, revised, reset and retired. - [Organizations and roles](https://codebook.work/docs/administration/organizations-and-roles): Where organizations and people are managed, what each role can do, and how removing somebody works. - [Model providers and token usage](https://codebook.work/docs/administration/model-providers): Shared SSO model configuration, metered calls and CodeBook token limits. - [AI Models](https://codebook.work/docs/administration/ai-models): Which model each feature of CodeBook asks, what it actually ran, and how a platform administrator assigns one. - [The security model](https://codebook.work/docs/administration/security-model): Deterministic first — the rules the system enforces rather than prompts — plus authorization on every write, workspace isolation, per-station grants and the audit trail. - [Implementation status and current limits](https://codebook.work/docs/administration/implementation-status): What the current code supports, what is partial, what is not built, and which responsibilities belong to SSO. - [Security infrastructure](https://codebook.work/docs/administration/security-infrastructure): Short-lived credential leases for runs, one outbound door with a per-factory egress policy, content scanning of uploads and artifacts, and a dependency gate on agent pull requests. - [Model policies and routing](https://codebook.work/docs/administration/model-routing): Pin a model, set a fallback chain, or let CodeBook choose from measured results — per factory, station or worker, among the models your organization already has at SSO. - [Managed service mode](https://codebook.work/docs/administration/managed-service): Let a provider organization read or operate your factories under a consented, revocable grant, with a provider console, per-customer SLA reports and white-label branding.