ADR-020: Agentic Company Governance — Paperclip + MCP

Status: 🟢 Accepted Triggered by: Agentic-Led Company spec (docs/strategy/agentic-led-company-spec.md) Date: 2026-04-17

---

Context

The Agentic-Led Company Spec defines a governance model where AI agents perform work across all company departments (Engineering, Marketing, Customer Success, Product, Domain Expert, Knowledge Synthesis, Co-Founder Strategy). The spec requires:

1. Event-driven agent architecture with bounded contexts (§3)
2. Proactive task surfacing with a Founder Task Board (§4)
3. Three-stage review pipeline: Self-Review → Supervisor → Founder (§5)
4. Standardized Management Reports with progressive disclosure (§6)
5. Blast radius classification governing approval requirements (§7)
6. Immutable audit trail for all agent activity (§9)

Four implementation strategies were evaluated:

Strategy	Description
A: Pure Paperclip	Deploy Paperclip (open-source agent orchestration platform) as-is, connect to Busflow via MCP
B: Hybrid	Paperclip for scheduling/budget, custom layer for events/reports
C: Custom Build	Build governance layer from scratch using existing Hasura/NestJS/BullMQ/n8n stack
D: Fork Paperclip	Fork and reshape Paperclip, replacing UI and extending with spec features

---

Decision

Strategy A: Pure Paperclip + MCP bridge.

Deploy Paperclip as a standalone governance platform. Connect agents to Busflow systems via MCP (Model Context Protocol) servers. Agent system prompts and MCP tool scoping enforce the spec's governance principles — no custom code required.

Rationale

1. Zero governance code to build. Paperclip provides heartbeat scheduling, budget enforcement, atomic task checkout, approval gates, and audit trails out of the box. Building these from scratch would cost 6-8 weeks with no product value gained.

2. MCP tool assignment achieves bounded context enforcement. Each agent receives a scoped set of MCP servers — Engineering gets mcp-server-hasura + mcp-server-github; Marketing gets analytics-only tools. This implements §3.2 (Bounded Contexts) without custom access control code.

3. Spec principles belong in prompts, not in infrastructure. The three-stage review pipeline (§5), Management Report format (§6), and self-analysis requirements are output format concerns. System prompts enforce them more flexibly than custom code, and they can iterate rapidly without deployment.

4. Premature optimization avoidance. The spec defines governance for a mature agentic company. The company has zero running agents today. Building typed domain events, three-stage review pipelines, and blast-radius classification gates before running a single agent workflow is premature. Start with Paperclip, discover what governance is actually needed, and evolve.

5. Standalone deployment. Paperclip runs its own Postgres, its own Node.js server, and its own Docker container. It communicates with Busflow exclusively via REST webhooks and MCP — no shared database, no monorepo coupling. Clean separation: Paperclip owns "running the business," Busflow owns "the product."

Rejected Alternatives

Strategy	Why Rejected
B: Hybrid	Two systems to maintain (Paperclip + custom layer) with integration coupling. Worst of both worlds
C: Custom Build	6-8 weeks of development for features that Paperclip provides. Premature — we don't know which governance features matter yet
D: Fork	Same build effort as custom (~5-7 weeks for UI rewrite + integrations) with added fork maintenance burden. The React UI rewrite costs the same as building a new Nuxt app

Evolution Path

Strategy A (now)  ──►  Strategy D (if needed)  ──►  Strategy C (if needed)
Pure Paperclip         Fork + select additions       Full custom build
+ MCP bridge

Trigger for A → D: Paperclip's approval model is too coarse (need blast radius tiers), structured reports are a must, or a dedicated Supervisor LLM review pass cannot be modeled as a "manager agent."

Trigger for D → C: Fork merge conflicts become unmanageable, or governance needs deep integration with Busflow product data (shared DB, Hasura subscriptions).

---

Consequences

• Paperclip deployments join the Docker Swarm stack as a standalone service (see MCP Agent Bridge Protocol).
• MCP servers must be developed for Busflow data access: mcp-server-hasura (product data), mcp-server-busflow-api (NestJS actions), mcp-server-n8n (automation triggers). Each domain team receives MCP servers scoped to its bounded context.
• Agent teams map to DDD bounded contexts. Four domain teams (Commerce, Backoffice, Operations, Communications) replace a single Engineering domain. Each team runs a PM/Engineer/QA triad restricted to its monorepo directories (see spec §3.2, §3.2a).
• Cross-session learning via .knowledge.md. Each domain maintains a .knowledge.md file for accumulated learnings. QA agents write on failure; Engineer agents read on wake (see spec §3.4).
• Agent system prompts must enforce spec principles: self-review section (§5.2), confidence/assumptions format, source citations, scope compliance declaration.
• The React dashboard ships as-is. No Vue/Nuxt rewrite. The founder uses Paperclip's React UI until the docs justify a custom UI.
• The spec remains the canonical governance reference. Paperclip is the runtime; the spec defines the principles. As agents produce real output, the spec evolves based on observed governance needs.

---

Cross-References

Document	Relationship
agentic-led-company-spec.md	Governance spec (principles source)
mcp-agent-bridge.md	MCP integration protocol
ai.md	AI architecture (§Agentic Company Governance)
workflow-orchestration.md	Product automation layer (n8n/BullMQ — distinct from agent orchestration)