The Method
C² — the AI-native build method.
A document-driven method built on one architectural insight: every software project runs two parallel systems — a codebase and a contextbase. Traditional methods optimise the code. C² optimises both, and treats their relationship as multiplicative.
01What C² Is
Two systems, not one
C² (C-Squared) is a document-driven, AI-native software development method built on one insight: every software project has two parallel systems — a codebase (what runs) and a contextbase (what guides).
The contextbase — PRDs, session briefs, gotcha logs, decision records, patterns — is written as part of development, lives in the same repository as the code, and is read by AI agents before they touch anything. After 50 sessions it is denser in decision context than the codebase itself. After 200 sessions it is irreplaceable institutional memory.
This is not a documentation culture. It is an execution infrastructure.
02The Equation
P = aic² is a mnemonic, not a law of physics. Read it plainly: productivity comes from AI applied to your two systems — Context and Code. The “squared” is the two Cs, not a literal exponent. If either C is zero, productivity collapses regardless of AI capability: a brilliant AI with no contextbase is improvising; a rich contextbase with no working code is documentation.
The two systems multiply each other. A richer contextbase makes AI-generated code more precise; better code surfaces insights that enrich the contextbase. Context improves Code; Code improves Context. That’s the compounding loop the method exists to capture — the real claim under the mnemonic.
All three are live levers — not constants. A 2× better model, 2× richer Context, and 2× better Code compound to 8× (2 × 2 × 2). When a new model ships, every C² project benefits overnight: the contextbase doesn’t need rebuilding, and a stronger ai reads the same compounded Context and Code.
| P | Productivity — features shipped, quality held, knowledge retained |
| ai | The AI crew — capability of the agents executing under human direction |
| c | Context — the contextbase: briefs, patterns, gotchas, decisions |
| c | Code — the codebase: the software that runs |
| c² | Context × Code — the two Cs multiply each other |
03Prompt · Context · Harness
Where C² sits
Three nested layers, each containing the one before: prompt engineering (the message — one composed input), context engineering (the memory — what a curator keeps or drops in a finite window), and harness engineering (the machine — the gather → act → verify loop that retries on failure).
C² is a harness method. The Prompt Brief is its prompt layer; the contextbase and the .md Router are its context layer; the Cascade and the verification chain are the harness. “Isn’t this just prompt or context engineering?” — no. C² sits at the harness layer and contains both.
04The Pilot Model
The developer is a pilot, not a crew member
A crewman hauls rope. A pilot sets course, reads instruments, makes decisions, and directs the crew. AI agents are the crew — they write code, run tests, manage files, generate documentation. The pilot scopes the work, reviews output, makes architectural calls, and owns the quality bar.
The reframe matters structurally. It changes what the human works on:
Crewman — wrong
- Writing boilerplate
- Chasing a bug for three hours
- Typing out a test
- Updating documentation after the fact
- Measures output in lines written
Pilot — right
- Writing the brief that constrains the boilerplate
- Invoking the debug limit and escalating
- Specifying testable acceptance criteria first
- Writing the session brief as part of the session
- Measures output in decisions made
The posture is constant. The bottleneck isn’t.
The pilot directs at every scale. What changes is what constrains them — four stages of one role, not four different roles:
Assisted
one agent
Your attention is the bottleneck. Trust is low and there's no self-verification, so you read everything and never look away — the work is synchronous, and you sit and watch. The question you're asking: do I need to read this?
Parallel
several, isolated
Review throughput is the bottleneck. You hand-write less and check several streams instead, each agent verifying its own work before you see it. The question: can I review this fast enough?
Supervised autonomy
beyond reading
Trust in the loop is the bottleneck. 'Did you read the code?' stops being the right question. What replaces it: what context was the model missing, and how do we fix that for next time? That answer goes straight into the contextbase.
Intent-steered
by exception
Identifying what to automate is the bottleneck, along with matching guardrails to each kind of work. The question: is this something an engineer would have done?
Two transitions carry the weight, and C² already builds both. Assisted to parallel needs a self-verification loop you trust — tests, build, lint, an end-to-end run against a real environment. That’s anchors, arrived at from a different direction. Parallel to supervised autonomy needs a way for the agent to pull in context: code, decisions, discussion. That’s the contextbase, named as the gating capability for autonomy.
And there are two ladders, not one. This one grades by agent count and your role. The other grades by risk of the work — crawl, walk, run. They’re orthogonal, and both are true: a team can sit at run on risk and still at assisted on count — one agent working unattended overnight on well-fenced tasks, with a pilot who reads every diff in the morning. Ask which axis you mean before you claim a level.
It also tells you when the graph is your move. If you aren’t already running concurrent agents behind a self-verification loop you trust, the graph isn’t your next step — the loop is.
05The Cascade — 6 Tiers
Every piece of work flows through one chain
Each tier has a defined frontmatter contract and a folder lifecycle: backlog → in-progress → review → done.
Platform PRD
└── Feature PRD ← one per feature, a living document
└── Prompt Brief × N ← the atomic build unit
└── Task × N ← zero is fine for small briefs
└── Session Brief ← every session, no exceptions
└── Release Note (optional, on completion)
└── Weekly Announcement (optional, Friday roll-up)It doesn’t terminate. It closes on the PRD.
Release Notes and Weekly Announcements are optional roll-ups, so on paper the chain trails off into artefacts a team may never write. The chain is really a loop, and the PRD is its spine. Read the PRD → write the PRD: every ceremony either reads it or writes back to it, and nothing lives in a second place. The loop opens at Flight Planning, runs through the build and the gates, and closes when what was learned lands back on the PRD — which goes out again, richer, as the next version.
Feature PRDs are living documents
Not frozen at creation. One PRD per feature, evolved in place — and versioned and compounding: v1.0 → v1.1 → v2.0, where each version absorbs the last. A bank switch, leaving one live artefact that says where the work is now rather than restarting from it. A PRD that doesn’t change is a PRD nobody is reading.
Prompt Briefs are the atomic build unit
Where the pilot-to-crew handoff happens. The brief specifies what to build, what not to build, what to read first, and the acceptance criteria. Brief quality is the bottleneck — not the AI’s capability. Size each one so that one brief ≈ one pull request: a brief that can’t be expressed as a single reviewable PR is really two briefs. Each carries a test plan for its own slice, so nobody downstream is handed an untested build.
Session Briefs are AI memory
Every session, no exceptions. AI agents have no memory between sessions; the session brief is the mechanism that provides it. It is written any time context is about to break — a phone call, a meeting, closing the laptop, hitting the context limit — not just at end of day. The question is never “is the session finished?” but “if I came back to this cold, what would I need to know?”
It also carries the landing zone — believed delivery date and how far along the work is. That’s what actually replaces the stand-up: anyone can see who is flying what, when they expect to land, and how far in they are, by reading the trail instead of interrupting the pilot. Set an honest bar — one to two briefs on an active build day — and hold it mechanically rather than virtuously, with a CI check on any PR that touches application code. A rule that depends on remembering is a rule that decays.
06Flight Planning
File the plan before takeoff. Close it on landing.
The Cascade hands you a set of briefs. Flight Planning is what you do with them before an agent burns a session: you file a plan, and other people look at it. At agent speed a vague plan no longer costs a slow afternoon — it costs a whole session pointed the wrong way, and you find out when you read the diff. It’s the gate between I have a PRD and I’m running build sessions against it.
What a filed plan contains
The line
the boundary
The explicit scope boundary — this is what I'm going to build, and this is what I'm not. Drawing the line is the act that turns a wish into a route.
The briefs
the work
One Prompt Brief per atomic unit, each cleared against the 6-item quality gate and naming its anchor. A single PRD often files as six or seven.
The journey
when
Milestones, a believed landing point, an ETA. Not a hard deadline — a filed expectation, so deviation is visible.
The shape
how it's wired
The topology of the brief set: which briefs are independent and can run at once, which are joined by an edge and must sequence, where they merge, and which results get an independent pass before they count. Cheap to add, because every brief's pre-flight table already declares its surface.
The red line
optional
A couple of pages mocked up in a feature branch — look-and-feel to react to. You'll bin it, but it translates the idea faster than a paragraph ever will.
The plan is the execution contract
Filing the shape is what makes the plan more than a review artefact. It sits above the briefs and decides how they run — three levels, of which only the third needs a plan to settle it:
- The brief is the node — one bounded job, contracted by the quality gate and the pre-flight table, with an anchor that decides done.
- Inside a node, execution is a loop — read, implement, review, verify, commit, with the anchor as its stop condition and the blocker limit as its escape hatch.
- Between nodes, the plan draws the graph — edges, the barrier, verified edges. A node can’t see its siblings and a loop can’t see outside itself, so this is the one level that needs a plan.
So the plan decides the wiring, and every brief runs its loop inside whatever wiring it’s given. And the shape is always drawn — sometimes it comes out a line. A line is a graph with one edge in and one edge out, so filing “this is a line, and here’s why” is a finding. Never asking is the failure.
The plan doc itself is a throwaway — a meeting agenda, not a third source of truth. The PRD and its briefs stay canonical. Fold the decisions back in and bin the plan.
Three gates, at three altitudes
A cycle passes through three human gates, and the most common mistake is treating them as one. Flight plan (per PRD) asks is this the right route, and is the plan flyable? — held by the owner of the intent, before any build. Pull request (per PR) asks does this build do what its brief said? — held by engineering, the QA evidence and a peer. Closing (per PRD) asks is the shipped thing right, and what did we learn? — held by the same owner who cleared the flight plan.
The middle gate is correctness. The outer two are judgement, held by one owner, bookending the build. That symmetry is the point: the person who cleared the route is the person who confirms the landing, which is what stops a plan being approved by one standard and accepted by another.
Closing the Flight Plan
A filed plan has to be closed on arrival. That’s not a metaphor stretched for effect — it’s the aviation fact the ceremony is named after. Land without closing and air traffic control starts a search, because an open plan means an aircraft unaccounted for. C² had a ceremony for takeoff and none for landing.
It sits at a higher altitude than the PR gate — not is the build correct? but is the shipped thing right? — and it carries the lens engineering review structurally can’t apply: does this meet the intent, and does it look right against the design system. Run that lens whether or not a designer is in the room, so it never gets skipped.
The landing
what shipped
What was actually built, against the line that was drawn.
The deviation
where it changed
Where the route changed and what you decided in the air. Zero judgment — the plan exists to make drift visible, not to punish it.
The anchor
the evidence
The signal that decides done. Tests that ran. The query that returned rows. The deploy that resolved. Not the agent's account of any of it.
The learning
what compounds
What the contextbase gains: gotchas, patterns, decision records, the PRD's completion rationale, estimated against actual.
It isn’t a demo and it isn’t a retro. It’s a gate, and someone in it needs the authority to say not yet. With a crew that’s two people — whoever owns the intent and whoever owns the implementation. Alone, it’s you reading the diff and asking whether the agent did what you actually wanted. Same ceremony, different weight, and the solo builder is the one who most needs it and most easily skips it.
The findings need structure, or they evaporate. A review produces a pile of we should fix that and we should add that, and in most rooms it dies in the room. What stops that is cheap: every finding gets a stable ID written onto the PRD in one section, tagged FIX (wrong today) or ADD (new capability) — conflating those is how a bug list turns into a roadmap and nothing gets fixed. Flag the keystone, the one that unblocks the rest, and sequence from there: keystone, trust fixes, high-value adds, design pass. The PR that resolves one references its ID, so the trail runs review → PRD → PR → shipped and is auditable from git alone.
And the sweep belongs to the next flight plan, not to the closing. A findings section that only grows will drown the PRD in its own history. So the next plan sweeps at the version bank-switch: durable decisions promoted into the spec or the knowledge base then cleared, done admin cleared outright — the trail lives in the closing PR, the release note and the git log — unfinished items carried forward, and the feature list reconciled against what actually shipped. The closing appends at the end of a cycle. The next flight plan sweeps at the start of the next. That pair is how a PRD compounds without hoarding, and it’s the mechanism behind “living, not frozen” — which is otherwise just a sentiment.
Flight Planning is where context is spent. Closing is where context is made. C² already asked for every artefact the closing produces — the session brief, the knowledge capture, the completion rationale, estimated against actual — and asked for no ceremony that produces them. They depended on discipline at the exact moment a team feels finished. That’s the worst possible moment to depend on discipline, and it’s why the closing gate is where the loop actually closes — back onto the PRD, which goes out again as the next version.
07Codebase + Contextbase
The self-improving layer
Treating docs/ as equally important to apps/ — and having the AI write to both — is C²’s most distinctive structural commitment.
project/
├── apps/ ← codebase (what runs)
└── docs/
├── 01-planning/ ← PRDs, strategy, methodology
├── 02-working/ ← Prompt Briefs, sessions, tasks, releases
├── 03-knowledge/ ← Patterns, gotchas, ADRs ← the self-improving layer
├── 04-operations/← Deployment, runbooks, debugging
├── 05-reference/ ← Tech stack, naming, constants
└── 06-agents/ ← Agent team design, roles, protocols, reviewsThe 03-knowledge/ directory is the highest-compounding asset. An agent discovers a quirk, extracts it to gotchas/ in the same session, and the next session reads the knowledge index before touching relevant code. The gotcha never costs the team time again. Gotcha capture is not optional: a session brief with a non-empty Key Discovery is not complete until the knowledge file is committed in the same session.
The Router
One file your agent reads first — the living index of the whole contextbase. We call the concept router.md; on disk you name it for your agent so it’s read automatically: AGENTS.md(the emerging cross-agent default — Codex, Cursor, and most), CLAUDE.md for Claude Code, GEMINI.md for Gemini CLI. Ship it agent-correct from day one — never rely on a rename you’ll forget.
The Router links rather than embeds, so the agent pulls only the slice the work needs — lazy-loading is the compression. And it’s maintained: as the project grows you add reference points, lists, and links, so the Router becomes the project’s living wiki — the curated entry point that keeps every session lean.
How context stays lean
The contextbase will outgrow any model’s window. C² keeps the working set small with three mechanisms, at different timescales:
Session Brief
point-in-time
At every context break, digest the session down to 'what the next agent needs cold' and drop the raw transcript. Compaction triggered by the break, not by the window filling up.
The Router
continuous
Links instead of embeds, and is kept current — so each session loads a lean, curated slice rather than the whole contextbase. The living index does the compressing.
The Learn loop
capture → consolidate
During the session, capture discoveries fast — classify each (gotcha, pattern, ADR) and write it to 03-knowledge/ so it's never lost. Periodically, consolidate: merge duplicates into canonical docs and refresh the Router's links. The wiki stays current without sprawling.
When a single session’s working set still overflows the window, borrow in-session compaction (à la HumanLayer’s ACE). C²’s three mechanisms handle the durable, cross-session half.
08The Agent Team
Agent-agnostic by design
C² works with any AI coding agent that can read files, write files, and commit to git — Claude Code, Grok CLI, Gemini CLI, Codex, Cursor. The contextbase is plain markdown. Choosing C² is not a commitment to a vendor; it’s a commitment to a method. When a better agent ships, the contextbase transfers intact.
Lead Agent
executes
Reads the contextbase, writes code, manages git, extracts knowledge, writes session briefs. One agent leads per codebase surface — running multiple agents on the same surface creates conflicts and incoherent briefs. Surface is the constraint, not headcount.
Bench Agents
reviews, never executes
Independent review on high-stakes calls — PRDs, security, architecture. Budget-capped. Independence is mechanical, not attitudinal, and takes three conditions: a different model from the one that wrote the code, inputs the author doesn't control (run it in CI, from the criteria and the diff), and teeth — a dispute blocks the merge. A review inside the builder's context is the builder agreeing with itself in a different font.
Specialist Agents
scoped subagents
Tightly-defined roles for repeatable tasks — QA review, release-note authoring, security review. Defined in .claude/agents/ (or equivalent) with a documented protocol.
The multi-agent anti-pattern — multiple agents mutating the same surface at once — burns cost, produces contradictory output, and makes session briefs impossible to write. It emerges from urgency: throwing more agents at a blocked session. Clarify the brief instead, and let one agent proceed.
Topology — when agents may run concurrently
That anti-pattern is about contention, not concurrency, and conflating the two reads as a ban on parallelism. It isn’t one. The rule: agents may run concurrently exactly when no edge connects them and no surface is shared. An edge means one agent’s output is another’s input. A surface is everything an agent mutates or contends for — files, data, external resources, a deploy target. Two agents on one surface is the anti-pattern, however urgent the session feels. Twelve agents on twelve disjoint surfaces, each with a brief that clears the quality gate, is the method working.
Lead-and-bench stays sequential because there is an edge — the bench reviews what the lead produced. Sequence what’s connected; run what isn’t. Worktree isolation is the seatbelt for the one topology that needs it, parallel writes — not a tax on every run. And a surface is wider than a file list: the failure that catches people is false independence, two agents whose briefs never mention each other colliding over a shared database, a rate-limited API, or one deploy target. Anything shared is a hidden edge, and hidden edges bite hardest because no brief says they exist.
A graph buys breadth. It does not buy judgment. Skip it when the task is small or isolated, when the work is exploratory and needs steering, when the steps genuinely depend on each other, or when you want to approve every step. The tell: if you can’t find two briefs with no edge between them, there is no graph to build — it’s a loop, and a loop is the right tool most days. And the objection that a graph runs wide without you has a direct answer: the pilot’s gate is at filed, not at every node. A pilot doesn’t approve each aileron movement; they file a route, fly it, and own the deviation. Approve the topology, not the traffic.
Node
one agent, one bounded job — a Prompt Brief
Edge
the artefact that crosses — output becomes input
Barrier
where parallel work merges — earn it
Isolation
one node's mess can't reach the others
Verified edge
an independent pass before the result counts
Anchor
the signal no agent can produce by asserting it
The vocabulary is structural, not tool-specific. C² already had all six under other names.
Anchors — what makes a result count
Don’t loop on confidence. Loop on evidence. “The agent says it’s done” is not a stop condition, and neither is “the review passed” when the review read the builder’s own account of the work. Agents all checking each other’s reports produce something consistent and unverified. It fails the way one agent fails — only later, more expensively, and with far more green lights on the way down.
An anchor is a signal no agent in the run can produce by asserting it. A test that actually ran — not “should pass”, did pass. A query that returned rows. A deploy that resolved. Every Prompt Brief names one, folded into the gate’s testable-acceptance-criteria item rather than sitting beside it. The gate stays six items. Item three now asks which signal decides, and whether the agent can fake it.
Frozen rules are the companion idea — rules marked non-negotiable precisely because they’re the ones under pressure, the ones an optimiser would bend to win. The write-path check after a constraint migration. The file-size cap. Never fabricate data to make the software look like it works. Every one of them exists because it was bent once and something broke. A system is only as honest as the things inside it that refuse to move.
09The Principles
Six principles. Pilot in command.
AI-augmented teams create faster than they complete — speed without command becomes drift. Six principles keep you the pilot, not a passenger:
A · Fly the plane
own it
One human owns each PRD from intent to a verified outcome — accountable for the landing, not just the takeoff. Keep the cockpit small: you can only truly fly a few at once. Done means the result moved, not that code shipped.
B · No takeoff without a flight plan
brief it, trim it
A PRD becomes active work only as a Prompt Brief the agent can fly — and the brief cuts the mission to what matters, in small legs you can turn back from in minutes. No brief, no flight.
C · Build the autopilot
systematize it
Never do the work twice. Don't write the blog — embed the system that runs it. Don't work the pipeline by hand — build the agent that runs it. Ship the machine that produces the output, not the output.
D · Earn the green light
verify it
An agent hands you confident, wrong code at machine speed. Its output is a proposal, not product: it ships when the tests pass and a human clears it. Don't loop on confidence — loop on evidence. And close what you file: a flight plan nobody closes is create-not-finish drift with better paperwork.
E · Every flight makes the next one better
compound it
Each delivery updates the contextbase, so the next agent starts from the new baseline — not from scratch. The team gets smarter every loop. That's the c².
F · Fly the formation
govern the spend
A fleet breaks the arithmetic one agent and a budget-capped bench was built on — the run that cost one call now costs forty. One published port hit roughly US$165,000 in eleven days. Spend the expensive model where judgment lives, cheap ones on bounded repetitive work, plain code on the plumbing. Earn every barrier: it makes every agent wait for the slowest. And declare the width in the plan before the fleet launches.
10What C² Emphasises
Where C² puts the weight
Few of these are unique in isolation — native rule files, BMAD, and HumanLayer’s ACE each share a piece. C²’s contribution is combining them into one lightweight, agent-agnostic discipline, and treating the contextbase as an investment that compounds.
- 01
The Pilot mental model as a scope constraint
Not a metaphor — it makes the wrong behaviours feel obviously wrong rather than heroic.
- 02
The contextbase as a first-class product artefact
docs/ treated as equally important to apps/, with the AI writing to both.
- 03
The autonomous execution contract
A pre-flight listing exact files and line ranges forces the author to think like an architect before the agent touches anything.
- 04
The .md Router pattern
One entry point the AI reads first, lazy-loading exactly the context the work needs.
- 05
Knowledge capture to git as compounding memory
Gotchas, patterns, ADRs — written by the AI, read by the AI. It accumulates instead of evaporating when people leave.
- 06
Session briefs triggered by context breaks
Not the clock. Any break that resets AI context triggers a brief.
- 07
Multi-AI review as structured practice
Lead + bench with budget controls and close-the-loop Actions Taken tables — not ad hoc 'ask ChatGPT'.
11Prior Art
C² isn’t alone — and that’s the point
The real differentiator in 2026 isn’t the model — it’s how systematically you manage context. A lot of good people are converging on that, because it works. Here’s the honest landscape and where C² sits in it.
Native rule files
CLAUDE.md · AGENTS.md · .cursorrules
The baseline every agent supports. C² isn't a replacement — it's the method around these files: what goes in the router, how it lazy-loads, and the brief/knowledge structure it points to.
BMAD
agent-persona SDLC
Breakthrough Method for Agile AI-Driven Development — a heavier, orchestrated pipeline with specialised AI personas (PM, Architect, Dev, QA). C² is lighter and agent-agnostic, centred on the contextbase rather than a persona workflow.
HumanLayer ACE
context compaction
Advanced Context Engineering — disciplined window management and intentional compaction (research → plan → implement). Complementary: C² is where the context lives; ACE's compaction is how you keep the working slice lean. Worth borrowing.
Pocock / Packmind / Anthropic
workflows · ContextOps · the umbrella
Matt Pocock's PRD→issues→autonomous workflow shares the spirit; Packmind treats context as an enterprise lifecycle; Anthropic's 'context engineering' writing is the broader discipline C² implements with the specific vocabulary of a contextbase.
The pre-AI and academic lineage
C²’s closest pre-AI ancestor is Shape Up (appetite, outcome focus, no sprint theatre); its closest academic peer is AWS AI-DLC.
| Shape Up | AWS AI-DLC | C² | |
|---|---|---|---|
| Human role | Shaper | Approver at gates | Pilot — directing throughout |
| Context model | — | Delivery (load & use) | Contextbase (invest & compound) |
| Knowledge | Tribal | Not specified | 03-knowledge/ in git, self-improving |
| AI integration | None | Agent-agnostic pipeline | Native — exists to direct AI |
| Documentation | Basecamp | Rule files per phase | Repo-native markdown, compounds |
C²’s lane: the lightweight, agent-agnostic end of this spectrum — contextbase-as-investment, a clean brief cascade, and the Pilot model, formalised from real production work rather than theorised up front. Mix in ACE’s compaction or BMAD’s workflows where they fit; these approaches compose.
For a fuller side-by-side, read AI development methodologies compared or an alternative to Agile.
12The Proving Ground
Built in production, then formalised
C² wasn’t designed up front and then tried out. It emerged from two years of production software delivery across real commercial products, under real pressure, and was formalised afterward from what actually held up.
Built with C² across two years and 1,000+ AI agent sessions — shipping a range of real production software: SaaS platforms, websites, agents, and ecommerce stores. Every template in the method came from that build.
No anonymous percentages. No certification funnel. The method is the contribution — free and open, forever, and yours to adapt. The proof is that it shipped something real, and the commit history is public.