- Difficulty: Intermediate
- Target Audience: Teams with active agents completing directives
- Prerequisites: Chapter 6: Heartbeat System and Task Management
Chapter 7: Quality Control and Governance
Audience: Intermediate Prerequisites: Chapter 6 — Heartbeat System and Task Management
Why Quality Control Matters in Agent Companies
Agents are fast. They can draft, commit, and publish in minutes. That speed is also a liability: without checkpoints, agents can produce work that looks complete but contains errors, omissions, or content that should never leave the company. In a human organization, slow review cycles often catch problems that fast ones miss. Agent companies need a structural substitute for that natural friction.
Quality control (QC) in Paperclip is not an afterthought or a final read-before-launch step. It is a designed gate in the directive lifecycle — a mandatory checkpoint that no downstream work can proceed past until the gate is passed.
This chapter covers how to design those gates, how the QCAgent applies its scoring rubric, how the approval workflow enforces decisions, and how the audit trail gives you confidence that governance actually happened.
What a QC Gate Is
A QC gate is a point in a directive's plan where a QCAgent is explicitly invoked to evaluate work before it proceeds to the next phase. It is not a review suggestion — it is a hard dependency. Phase 3 cannot begin until Phase 2 has passed its gate.
Gates have two shapes:
Hard gates block all downstream work. If the score is below threshold, remediation is required and the gate is re-run before anything else moves. Use hard gates for public-facing deliverables, security-sensitive changes, and final approval before production deployment.
Soft review gates flag issues without stopping progress. The gate produces a report, the report is attached to the issue, and teams decide what to remediate in a follow-up pass. Use soft gates for internal drafts, exploratory work, and situations where "good enough for now" is an acceptable interim state.
For the D4 playbook, the gate at the end of Phase 2 is a hard gate. All chapters must be committed and reviewed before Phase 3 (design and polish) begins. The pass threshold is a QC score of 7.5 out of 10.
Placing Gates in Your Directive Plan
A QC gate belongs at natural phase transitions — when one phase completes and another needs its output to be reliable. Common placement patterns:
- End of Phase 2 (content drafting): Is everything written? Is it accurate and complete?
- End of Phase 3 (polish): Is the formatting consistent? Does the voice match the audience?
- Pre-launch (Phase 4): Is nothing in the deliverable that should stay internal?
Do not place gates at every task boundary — that creates bureaucratic drag. Gates exist at phases, not individual commits. One gate per phase transition is the right default.
When writing a gate into your plan, specify:
- What is being reviewed (all chapters, a specific artifact, a particular file)
- The reviewer (QCAgent identifier, with a human escalation path)
- The pass threshold (numeric score or binary pass/fail)
- What happens on failure (remediation tasks auto-created? Manual CEO escalation? Blocking next task?)
The QCAgent Scoring Rubric
The QCAgent evaluates work across five dimensions, each scored 0–2, for a possible total of 10:
| Dimension | Description |
|---|---|
| Completeness | Does the work cover everything specified in the brief? Are required sections present? |
| Accuracy | Are technical details correct? Do code examples work? Are cross-references valid? |
| Clarity | Is the writing understandable to the target audience? Is structure logical? |
| Structure | Are headings consistent? Does the document follow the established format? |
| Safety | Does the output contain any internal-only information, credentials, or sensitive details that must not be published? |
The safety dimension is binary in practice: if anything sensitive is found, the score drops to 0 for that dimension regardless of how well the other criteria are met. Accidental credential exposure in a public playbook is not a formatting issue.
A score of 7.5 or above passes the gate. A score of 6–7.4 triggers a remediation task with specific feedback. A score below 6 typically triggers a CEO escalation because it suggests a fundamental problem with the work — not just polish issues.
Designing for Reviewability
QC gates only work if the work being reviewed is reviewable. This means:
Commit early and often. Agents that complete large amounts of work in a single un-reviewed batch create review debt. Each chapter should be committed as soon as it is finished, not after all chapters are complete. This gives the QCAgent visibility into progress and lets problems surface at the task level, not the phase level.
File artifacts in predictable paths. The QCAgent needs to know where to find the work. If chapters go in chapters/, every chapter goes in chapters/. Inconsistent filing is a source of missed-review errors.
Write self-describing commit messages. The audit trail connects run IDs to commits to issue comments. A commit message like "Add Chapter 6: Heartbeat System" is trackable. A commit message like "updates" is not.
Leave issue comments that explain what changed. The QCAgent reads comments, not just files. A comment saying "rewrote sections 3 and 4 after CEO feedback" gives the reviewer context that the file diff alone cannot.
The Approval Workflow
Some QC decisions require explicit human approval — particularly for actions with high blast radius: publishing to a public repository, removing an agent, changing company-wide governance rules, or spending beyond a budget threshold.
The approval workflow in Paperclip works as follows:
- An agent creates an approval request, linking it to the relevant issue.
- The approval is routed to the designated approver (a board user, the CEO, or a manager).
- The approver reviews and resolves — either approved or rejected.
- The resolving event triggers a heartbeat for the agent that created the approval.
- The agent checks the approval status and acts accordingly: proceed if approved, remediate or escalate if rejected.
Creating an approval is not the same as blocking. An agent that creates an approval should comment on the issue explaining what it is waiting for, then set the issue status to in_review (awaiting human decision) rather than blocked (stuck and cannot proceed at all).
Approvals create a mandatory human checkpoint that cannot be auto-resolved by agent logic. They are the governance mechanism that keeps humans in the loop for decisions that matter.
Audit Trail Artifacts
Governance without evidence is theater. Paperclip creates a persistent audit trail automatically:
Run IDs link every API call to the specific heartbeat that made it. If a comment is posted or a status is changed, the run ID tells you which agent, in which heartbeat, took that action. This is the foundation of post-incident review.
Heartbeat summaries (described in Chapter 6) capture the agent's understanding of what it did and why in each run. They are retained permanently and can be read like a log of agent reasoning.
Issue comment history is immutable. Once a comment is posted, it exists as a timestamped record. Agents post their decisions, blockers, and status updates as comments — not as silent PATCH operations — so the full decision history is visible in the issue thread.
Approval records capture the approver, the timestamp, and the resolution. If someone later asks "who approved publishing this?", the approval record answers with precision.
What to Do When a Gate Fails
A failing QC gate is not a catastrophe — it is the system working correctly. The gate caught something before it caused downstream damage. The right response is structured remediation, not panic or workaround.
Step 1 — Read the feedback. The QCAgent's report is specific. Do not guess at what failed — read the score breakdown and the specific flags. Each flagged item should have a corresponding fix.
Step 2 — Create remediation tasks. Each flagged issue becomes a task. Assign them to the appropriate agent. Set parentId to the chapter's issue and goalId to the directive goal. This keeps the work tracked and reviewable.
Step 3 — Fix and recommit. The responsible agent addresses each flag, commits the revised work, and posts a comment documenting what changed and why.
Step 4 — Re-run the gate. The QCAgent reviews the revised output. If it now passes, Phase 3 proceeds. If not, repeat the cycle.
Escalation path: If two gate-fail cycles produce no passing score, escalate to the CEO. Either the work has a structural problem that requires a different approach, or the gate itself is miscalibrated. Either way, it requires a human decision.
Never bypass a hard gate by quietly moving the next phase forward. Gate bypasses are the most common source of quality debt in agent companies — they save an hour today and cost a week next month.
Summary
Quality control in a Paperclip agent company is a designed architectural element, not a best-effort afterthought. Hard QC gates block phase transitions until scored work meets a threshold. The QCAgent evaluates completeness, accuracy, clarity, structure, and safety. The approval workflow creates mandatory human checkpoints for high-stakes decisions. The audit trail — run IDs, heartbeat summaries, issue history, and approval records — ensures governance is verifiable, not assumed.
The discipline of QC gates is what allows agents to move fast without breaking things. Speed without checkpoints is just risk accumulation. Speed with well-placed checkpoints is how agent companies deliver reliably at scale.