CDLC: Context Development Life Cycle

CDLC means Context Development Life Cycle. It is a seven-phase operating model for the instructions, skills, knowledge, constraints, and evidence that coding agents use. SDLC manages the code agents produce. CDLC manages the context they receive.

Teams already do this work. They write a project guide, gather source material, assemble a prompt, test the output, share a skill, and revise the instructions after a failure. CDLC gives those activities one lifecycle so they can be reviewed instead of improvised.

What does CDLC mean in AI?

In AI engineering, context is an input you maintain. It includes more than a prompt: repository instructions, acceptance criteria, source documents, tool permissions, examples, prior decisions, and the evidence required to judge the result.

The seven CDLC phases are Generate, Compile, Test, Distribute, Deliver, Observe, and Adapt.

The output of CDLC is inspectable context: a small set of files, links, and constraints that another session can load and a reviewer can challenge.

A bead is a durable issue in the Beads work tracker: it can hold scope, dependencies, acceptance criteria, decisions, and evidence references. A fresh context is a separate, non-author session that receives the fixed intent, exact candidate, and check evidence so it can judge the work without inheriting the implementer's conversation.

The seven phases

1. Generate

Create or collect the raw material.

This can be a bead with acceptance criteria, a CLAUDE.md rule, a design document, official API documentation, a test fixture, or a short record of a decision. Generation is where you decide what the agent should know and which source is authoritative.

The failure mode is familiar: write one broad prompt from memory and let the agent fill in the gaps.

2. Compile

Select the material that belongs in the current task.

Compilation is editorial work. The implementing context may need an interface, the failing test, and the repository's error pattern. A fresh reviewer needs the acceptance criteria, the candidate diff, and the check receipts. Giving both contexts the whole repository adds noise and can hide the decision that matters.

A compiled packet should answer: what is the job, what is out of scope, what evidence counts, and where can the agent verify a claim?

3. Test

Check whether the context supports the intended behavior.

For a coding task, that means running deterministic checks and asking a fresh context to judge the candidate against unchanged acceptance. For a reusable instruction, it can mean running the same representative task with and without the change, then comparing failures instead of grading the prose.

The context that authored the candidate should not issue the binding verdict. AgentOps makes that separation explicit.

4. Distribute

Package context so another person, project, or runtime can use it.

Repository instructions travel with the repository. A skill can carry a procedure, scripts, examples, and references. A plugin can bundle skills and hooks. A wiki page can preserve a reviewed explanation and its sources.

Distribution is not copying a large personal setup into every project. Shared context needs an owner, a version, and a reason to exist outside its original task.

5. Deliver

Make sure the current session actually receives the context.

Some context loads automatically, such as a project CLAUDE.md. Some loads only when a skill is selected. Some must be linked from the active bead. Delivery fails when the file exists but the runtime never discovers it, or when a relevant page is buried under a pile of unrelated material.

Verify delivery from the agent's view. Do not assume that a file's presence means it entered context.

6. Observe

Record what happened after delivery.

Useful signals include a failed test, a fresh verdict, a review correction, an operator override, a repeated command error, or a production incident. Each signal points to a different possible cause. The code may be wrong. The task may be vague. The tool may be broken. The context may be stale.

Observation keeps those causes open long enough to investigate them. It does not turn every failure into a prompt problem.

7. Adapt

Change the maintained context when the evidence earns a change.

A recurring miss may become a new acceptance check. A decision may become a wiki page. A stale instruction may be removed. A failure in the delivery path may become a bead with a deterministic regression test.

Adaptation is explicit work. Nothing improves merely because another session ran. Someone or an invoked workflow must review the evidence, decide what generalizes, and keep the source attached.

Where the Knowledge Flywheel fits

The Knowledge Flywheel is one implementation of Generate, Observe, and Adapt:

Beads records the work and its evidence
  → review decides what is reusable
  → an LLM wiki preserves the reviewed lesson
  → a later bead links the relevant page
  → a miss opens repair work

Beads answers what happened. The wiki explains what a future session should know. The LLM helps with synthesis and linking; it does not promote its own output to truth.

That is a maintenance loop, not a learning law. Its value depends on retrieval, review, and deletion as much as capture.

A useful build order

Do not build all seven phases at once. Start where the missing evidence hurts.

1. Put intent and acceptance in one durable issue.
2. Give the implementing session only the sources and constraints it needs.
3. Run the real checks.
4. Ask a fresh context to judge the same acceptance and evidence.
5. Keep the result beside the intent.
6. Promote only repeatable lessons into shared instructions or a wiki.
7. Re-run a representative task after changing shared context.

This order produces a receipt at every step. It also reveals whether the bottleneck is generation, delivery, validation, or maintenance before you add more machinery.

CDLC and the 12 factors

The 12-Factor AgentOps principles supply guardrails across the lifecycle:

The factors do not make context self-improving. They make context work visible enough to review.

The two loops

The local loop is task-sized: generate, compile, test, deliver, and observe one packet.

The shared loop is maintenance-sized: distribute a proven instruction, watch how other tasks use it, and revise or retire it when the evidence changes.

The first loop produces a result. The second keeps a team from solving the same context problem in private. CDLC needs both, but the shared loop should grow only from work that has already earned a receipt.

Related

• The Knowledge Flywheel: Beads plus an LLM wiki, with the limits stated plainly
• The Validation Bottleneck: why independent judgment is the scarce part
• Reliable AI Agents Need a DevOps Feedback Loop: the delivery pattern behind the lifecycle
• Context Orchestration: selecting and delivering context for a bounded task
• AgentOps: one implementation of Plan, Implement, and fresh Validate