The context development lifecycle is the six-stage discipline, discovery and extraction, structuring and enrichment, validation, activation and serving, monitoring and freshness, and deprecation, that governs how business context gets built, tested, and kept trustworthy enough for an AI agent to act on. Atlan names its own six-step version of the engineering core of that arc, Build, Test, Review, Approve, Deploy, Learn, one capability inside the broader enterprise context layer. Two practitioners already use the literal phrase “Context Development Lifecycle”: Patrick Debois’s four-stage version for Tessl and Boden Fuller’s seven-stage version, but both scope it to AI coding agents writing software, not the enterprise business and data context this lifecycle governs.
| Field | Value |
|---|---|
| What it is | The discipline that governs how enterprise business and data context is built, tested, approved, deployed, and retired for AI agents |
| Core stages | Discovery/extraction, structuring/enrichment, validation, activation/serving, monitoring/freshness, deprecation |
| Direct analogy | Software got the SDLC once code became too complex to ship informally; context needs the same, for the same reason |
| Atlan’s named version | Build, Test, Review, Approve, Deploy, Learn (runs in Context Engineering Studio) |
| Formalize when | Roughly 3 to 30 agents in production, Atlan’s “Wall 2” |
| Not the same as | The coding-agent “Context Development Lifecycle” (Tessl/Debois, Boden Fuller), scoped to codebases, not business data |
What is the context development lifecycle for AI data?
Permalink to “What is the context development lifecycle for AI data?”Software engineering did not always have a formal lifecycle. Code shipped ad hoc until it got complex enough that informal handoffs started breaking production, so the industry built the software development lifecycle in response: plan, build, test, review, deploy, maintain. Patrick Debois, a co-founder of the DevOps movement, argues business context has reached that same point: “Context is the new bottleneck, not code.” That’s an outside validation of this page’s analogy, not an Atlan claim.
The context development lifecycle is the discipline that manages how enterprise business and data context gets built, tested, reviewed, approved, deployed, and retired, the same discipline software applies to code, applied to a different artifact: metric definitions, business glossaries, lineage, and policy, distinct from context engineering as the umbrella discipline.
This exact phrase is already used elsewhere with a different scope, worth naming plainly since a reader who found one of those pieces first will expect something different here. Debois’s Tessl post defines a four-stage CDLC (Generate, Evaluate, Distribute, Observe); Boden Fuller’s independent version runs seven. Both scope it to AI coding agents: codebase conventions, specs, architecture. This page scopes it to AI agents working on enterprise business and data context instead.
Atlan already names its own version of this narrower arc, Build, Test, Review, Approve, Deploy, Learn, one of five Context Layer capabilities and the engineering core of the fuller six-stage arc below. Academic research on context engineering (Mei et al., arXiv, 2025) independently decomposes the broader discipline into retrieval and generation, processing, and management, a similar three-part shape to the stages below though not a direct one-to-one mapping, and a different question from context engineering vs. prompt engineering, which covers a single interaction, not a lifecycle. The stages aren’t new, borrowed from software on purpose; what changes is the artifact.
What are the six stages of the context development lifecycle?
Permalink to “What are the six stages of the context development lifecycle?”The context development lifecycle runs in six stages, moving raw business knowledge from scattered systems into something an agent can trust and act on:
- Discovery and extraction: raw context is reverse-engineered from connectors, data lineage, and documentation, the job Context Agents automate, landing as an agent context graph
- Structuring and enrichment: candidate context becomes a reusable, versioned semantic form, or a graph-native structure like Neo4j
- Validation: candidate context is tested against historical traces before it ships
- Activation and serving: approved context reaches agents at inference time, through MCP or another protocol
- Monitoring and freshness: deployed context is watched for drift; LLM context goes stale at three layers, vector indexes, caches, and prompt templates, per Streamkap’s Ricky Thomas (2026)
- Deprecation: context retires once the business fact behind it changes, closing the loop back to discovery
Atlan’s named Build, Test, Review, Approve, Deploy, Learn loop is the middle of this arc, the engineering core, the way an SDLC discussion spends most of its depth on build-test-deploy despite naming requirements and maintenance too. Context mining handles discovery specifically; a related context observability practice watches freshness in production. 2026 is already being called the year of context engines for this reason, and this six-stage view sits tighter than the fuller 5-phase context engineering framework, which spans an organization rather than one piece of context moving through production.
How does Atlan’s context development lifecycle work?
Permalink to “How does Atlan’s context development lifecycle work?”Build, Test, Review, Approve, Deploy, Learn: that’s Atlan’s own six-step loop, and it sits inside the structuring-through-deployment middle of the broader six-stage arc above, not a replacement for it, split roughly in half between what AI drafts (Build, Test) and what a human has to decide (Review, Approve, Deploy, Learn).
Build and test: AI drafts, AI checks its own work
Permalink to “Build and test: AI drafts, AI checks its own work”Context Engineering Studio implements the first two stages directly: AI drafts candidate context and tests it against historical traces before a human sees it. According to Atlan’s own product data, most customers using this workflow say AI-generated context beats their own human-written definitions on the first draft, a claim specific to the Build stage, not the lifecycle as a whole.
Review and approve: humans add the judgment AI can’t
Permalink to “Review and approve: humans add the judgment AI can’t”This is the stage SDLC has no exact equivalent for. A test suite passes or fails; business “correctness” is a human owner’s judgment call about what becomes canonical, and that owner is frequently not an engineer. Context Repos are the versioned unit of output here, the way Git repos function for software: reviewable, diffable, rollback-able.
Deploy and learn: production is the real test
Permalink to “Deploy and learn: production is the real test”Deployment hands approved context to the activation and serving layer an agent harness draws on at runtime, whether that arrives through an MCP-connected data catalog or a direct call. Every production failure becomes the next cycle’s Build-stage candidate, the same compounding pattern behind long-term context management for AI agents.
Atlan's six-stage context development lifecycle, where every production outcome becomes the next cycle's Build-stage candidate. Source: Atlan.
Inside Atlan AI Labs & The 5x Accuracy Factor
See the data behind why AI-drafted, human-approved context outperforms context written by hand alone, and what that means for the Build and Test stages of your own lifecycle.
Get the EbookHow is a context development lifecycle different from a software development lifecycle?
Permalink to “How is a context development lifecycle different from a software development lifecycle?”SDLC and CDLC borrow the same shape on purpose, but they manage different artifacts, and that difference is what actually matters. As independent practitioner Boden Fuller put it, “SDLC manages the code agents produce. CDLC manages the context they receive.”
| Dimension | Software development lifecycle (SDLC) | Context development lifecycle (CDLC) |
|---|---|---|
| Artifact managed | Code | Business and data context (definitions, policies, lineage) |
| What “correct” means | Passes a test suite, compiles | Matches business truth, which itself changes |
| Who reviews | Engineers, code review | Domain owners who may not be technical, plus agents |
| Failure mode | Bug, broken build | Stale or contradictory context an agent silently trusts |
| Deprecation trigger | Version bump, refactor | A business fact changes, e.g., positioning, org structure |
Some practitioners read “context development lifecycle” as DevOps with a new noun; versioned prompts, evals, and telemetry aren’t new ideas, and that skepticism is fair about the stages, borrowed from software on purpose. It’s less fair about the artifact: code compiles or it doesn’t, while context is judged against business truth that keeps moving, and its consumers include both agents and non-technical domain owners who can’t review a diff. AWS’s definition of SDLC, plan, design, implement, test, deploy, maintain, is the pattern this lifecycle borrows; the divergence is what gets managed, not how many stages exist. Their SDLC comparison is code-to-code; this one is process-to-process, enterprise business context instead of a codebase, and a context graph instead of a repository, the same boundary RAG vs. context engineering draws between a retrieval technique and a full lifecycle discipline.
When does an organization need to formalize a context development lifecycle?
Permalink to “When does an organization need to formalize a context development lifecycle?”Most teams don’t need a formal lifecycle on day one. Atlan’s own Three Walls framework maps that need to agent scale, not calendar time: 1 to 3 agents is still bootstrapping; 3 to 30 hits “Wall 2,” where lifecycle management stops being optional; past 30, sprawl and drift set in without one.
Two anonymized pain points from Atlan’s customer conversations describe what Wall 2 feels like, though neither counts toward a credentialed-expert minimum: “Marketing changed positioning last quarter. The SDR agent still pitches the old version” (CMO, Global 2000 company), and “When an agent gets it wrong, I can’t trace which piece of context caused it, let alone roll it back” (VP AI Platform, top-5 insurer).
The backdrop makes the stakes concrete: 95% of enterprise AI pilots deliver zero measurable ROI, according to MIT’s Project NANDA 2025 research, and Atlan co-founder Prukalpa Sankar has cited a similar pattern from her own conversations: “83% of organizations are actively experimenting with AI, yet only 17% are able to drive value.” Neither stat is specific to lifecycle management alone; both explain why formalizing one stops being optional past Wall 2.
Formalizing at this point also raises a question this page doesn’t resolve: who runs it. That’s the same organizational question enterprises asked about data ownership a decade ago, now mapped onto AI, the same open question broader context management strategies for enterprise AI run into past Wall 2.
What breaks without a context development lifecycle?
Permalink to “What breaks without a context development lifecycle?”Three failure modes show up reliably once an organization skips a formal lifecycle, and all three trace back to the same root cause: nobody owns the transition from “context exists somewhere” to “context is certified for an agent to use.”
- Context goes stale silently. An agent keeps using outdated business facts because nothing flags the drift, the same mechanism context freshness and context drift detection exist to catch before it reaches production.
- No review step exists. AI-drafted context ships without a human owner ever deciding it’s canonical, so nobody can be accountable for what an agent said when it’s wrong, a gap context engineering and AI governance is built to close.
- No traceability exists. When an agent gets something wrong, nobody can identify which piece of context caused it or roll it back, the exact complaint the VP AI Platform quote above describes, and the reason context versioning for AI agents matters as much as versioning code.
These failures compound across a growing agent fleet rather than staying contained to one bad answer, the pattern context management for multi-agent systems, agent context management, and enterprise AI context management tools all cover once dozens of agents share the same ungoverned context pool.
Context Gap Calculator
Estimate how much of the context your agents rely on is actually reviewed, current, and traceable back to a source.
Check Your GapHow do you choose a platform to run a context development lifecycle?
Permalink to “How do you choose a platform to run a context development lifecycle?”Choosing a platform for this comes down to whether it names an explicit lifecycle at all, or leaves context governance ad hoc and unauditable, the same baseline comparing context engineering platforms generally has to start from.
| Criterion | Why it matters | What to look for |
|---|---|---|
| Names an explicit lifecycle | Ad hoc governance can’t be audited | A stated Build/Test/Review/Approve/Deploy/Learn-equivalent process |
| AI-assisted build and test | Manual drafting doesn’t scale | AI that drafts and tests context against historical traces |
| Human review and approval | Correctness needs a human owner | A clear approval step before context becomes canonical |
| Drift and freshness monitoring | Stale context is invisible until used | Continuous checks against source-of-truth changes |
| Versioning and rollback | Context that can’t roll back can’t be trusted | A versioned unit of output, e.g., Context Repos |
| Traceability to source | Requires knowing where context came from | Lineage back to the origin system |
The closest external precedent for how a discipline like this gets formalized in stages is Google Cloud’s MLOps maturity model: Level 0 is manual and script-driven, Level 1 automates the training pipeline, Level 2 adds full CI/CD. A context development lifecycle follows the same maturity logic applied to context instead of models.
Five questions surface most of the gaps when evaluating a vendor directly: Does it name an explicit lifecycle, or is governance ad hoc? Who reviews AI-drafted context before it goes live? How does it detect context drift in production? Can deployed context be traced back to its source and rolled back? What happens when the business fact behind it changes? A vendor that can’t answer all five with a specific mechanism, not a policy statement, is asking a team to run this lifecycle by hand.
How Atlan approaches the context development lifecycle
Permalink to “How Atlan approaches the context development lifecycle”Enterprises tend to hit Wall 2 without realizing it: context accumulates ad hoc across a growing number of agents until nobody can say what’s canonical, what’s stale, or who’s accountable when an agent is wrong.
Context Engineering Studio runs the Build, Test, Review, Approve, Deploy, Learn loop directly: AI drafts and tests candidate context, humans review and approve it, and Context Repos version the output the way Git versions a codebase. This is the shift Mastercard’s chief data officer, Andrew Reiskind, has described publicly as moving from privacy-by-design to data-by-design to context-by-design, a framing that only makes sense as a repeatable process.
The practical effect shows in how the underlying semantic layer gets used. Workday’s VP of Enterprise Data and Analytics, Joe DosSantos, has described that pattern: the shared language a data team already built for people becomes something Atlan’s MCP server hands to AI directly, instead of getting rebuilt for every new agent. Explore Context Engineering Studio end to end, or read the build-out path in how to implement an enterprise context layer for AI.
Real stories from real customers: context that stays current in production
Permalink to “Real stories from real customers: context that stays current in production”"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
— Joe DosSantos, VP Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
AI Agent Context Readiness Checklist
Score whether your organization has the review, approval, and freshness checks a formal context development lifecycle requires before you scale past Wall 2.
Check ReadinessNeither quote is about the context development lifecycle by name, but both describe what it produces: a shared, MCP-servable layer of context that doesn’t need to be rebuilt for every new agent.
Context needed a lifecycle for the same reason code did
Permalink to “Context needed a lifecycle for the same reason code did”Context needs a lifecycle for the same reason code did: it got too important and too complex to manage informally. The six stages aren’t a novel invention, borrowed from software and DevOps on purpose, the same way Debois’s and Boden Fuller’s coding-agent versions borrow them for a different artifact. What’s genuinely different is the artifact: business context doesn’t compile or pass a test suite, it’s judged against a business truth that keeps changing, and it has to satisfy both an agent and a non-technical domain owner at once.
The practical signal to watch for isn’t a calendar date, it’s Wall 2: somewhere between 3 and 30 agents, informal context management stops scaling and an explicit lifecycle stops being optional. Whether that lifecycle belongs to a data team, an AI team, or a new hybrid role is still open, the same question data ownership raised a decade ago and AI is now raising again.
FAQs about the context development lifecycle for AI data
Permalink to “FAQs about the context development lifecycle for AI data”1. What are the stages of the AI development lifecycle?
Permalink to “1. What are the stages of the AI development lifecycle?”Palo Alto Networks’ AI development lifecycle has eight stages, problem definition through model monitoring, and it builds the model itself. The context development lifecycle is a separate, narrower discipline governing the business context an already-built agent consumes, not the model.
2. What are the 7 stages of SDLC?
Permalink to “2. What are the 7 stages of SDLC?”Planning, analysis, design, development, testing, deployment, and maintenance. The context development lifecycle borrows this same pattern, review, approval, deployment, ongoing maintenance, and applies it to business context instead of code.
3. How is a context development lifecycle different from a software development lifecycle?
Permalink to “3. How is a context development lifecycle different from a software development lifecycle?”SDLC manages code, and “correct” means the code passes a test suite. CDLC manages business context, and “correct” means the context matches business truth, which itself changes, reviewed by domain owners who may not be technical.
4. Who owns the context development lifecycle, data teams or AI teams?
Permalink to “4. Who owns the context development lifecycle, data teams or AI teams?”Most enterprises haven’t settled this yet. It’s the same organizational question companies asked about data ownership a decade ago, now mapped onto AI, resolved between data platform teams, AI platform teams, and the domain owners who hold the business knowledge.
5. What happens to an AI agent without a context lifecycle in place?
Permalink to “5. What happens to an AI agent without a context lifecycle in place?”Context goes stale silently because nothing flags the drift. Nobody reviews or approves what becomes canonical, so no one is accountable when an agent is wrong, and nobody can trace which piece of context caused it or roll it back.
6. How is context mining different from the context development lifecycle?
Permalink to “6. How is context mining different from the context development lifecycle?”Context mining is the upstream discovery and extraction stage: reverse-engineering business context from existing systems rather than writing it from scratch. The context development lifecycle is what happens once that context exists: structuring, testing, review, approval, deployment, learning.
7. What is context rot, and which lifecycle stage prevents it?
Permalink to “7. What is context rot, and which lifecycle stage prevents it?”Context rot is business context that quietly goes stale or contradictory while an agent keeps trusting it. The monitoring and freshness stage exists specifically to catch this, checking deployed context against source-of-truth changes before an agent acts on it.
8. Do coding-agent context frameworks like Tessl’s CDLC apply to enterprise business data?
Permalink to “8. Do coding-agent context frameworks like Tessl’s CDLC apply to enterprise business data?”No. Frameworks like Tessl’s and Boden Fuller’s manage context for codebases: specs, architecture, test suites. This lifecycle manages business and data context, definitions, policies, lineage, for agents that reason over enterprise data rather than write code.
Sources
Permalink to “Sources”- A Survey of Context Engineering for Large Language Models, arXiv
- The Context Development Lifecycle: Optimizing Context for AI Coding Agents, Tessl
- The context development lifecycle, jedi.be
- CDLC: Context Development Life Cycle, bodenfuller.com
- How to Keep LLM Context Fresh with Live Data, Streamkap
- What Is SDLC? Software Development Lifecycle Explained, AWS
- MIT Report Finds 95% of Generative AI Pilots Fail to Deliver ROI, Fortune
- MLOps: Continuous Delivery and Automation Pipelines in Machine Learning, Google Cloud
- What Is the AI Development Lifecycle?, Palo Alto Networks
- Re:Govern 2025 Opening Keynote, Prukalpa Sankar, Atlan
