Enterprise AI desperately needs a lifecycle for context

Every successful enterprise AI deployment begins long before anyone types the first prompt. Teams spend weeks defining business metrics, documenting policies, connecting enterprise systems, and explaining the rules and exceptions that allow an AI application to answer questions correctly.

Then the application launches and the business keeps moving. Finance changes how it recognizes revenue, sales introduces new pricing, legal revises a customer policy, or product launches a new capability. Each decision changes something an AI application needs to know, yet those changes rarely reach every application that depends on them. A definition updated in one system remains six months old in another, while a policy legal replaced last week continues guiding a support agent.

Enterprises already know how to keep data accurate and secure, but the meaning attached to that data often lives across documents, prompts, code, and individual applications. AI depends on both, and enterprises have spent far more time building infrastructure for data than for the business knowledge required to interpret it.

Companies know how to manage data, but they don’t yet know how to manage context

Context captures what data means inside a particular company, including how finance calculates revenue, which customer policy applies to a situation, and when an exception overrides a rule. Data can tell an AI what happened, while context tells it how the business understands what happened.

Revenue offers a simple example. A customer record might show $500,000 in annual revenue, and the number might be completely accurate, but an AI application still needs to know whether the company considers that ARR, recognized revenue, bookings, or contracted value. It needs to know which products count and whether finance recently changed the definition. Those answers come from decisions the business has made about how to interpret the number.

The same problem runs through customer policies, product information, contracts, and support procedures. Retrieval can locate the relevant information, but the application still needs the business rules that govern how to use it.

Today’s AI implementations create tomorrow’s maintenance problems

I’ve seen companies solve this in almost every way imaginable. Business knowledge ends up in GitHub repositories, internal documentation, prompt libraries, and shared folders, while someone copies a policy into ChatGPT, another team builds an MCP server, and the analytics group maintains its own definitions in Looker. RAG pipelines retrieve documents, and each approach can get an individual application working.

Six months later, somebody has to remember everywhere that knowledge went when the business changes it. When finance changes a definition or legal changes a policy, someone has to know which prompts, documents, and systems contain the old version.

One business decision can create work across dozens of AI implementations because the organization copied the knowledge behind that decision into dozens of places. When someone changes a value in an authoritative data system, applications querying it can receive the new value. When someone changes the meaning of that value, companies rarely have an equivalent process for recording the change and distributing the approved definition.

Software engineering solved this problem decades ago

When I look at how companies manage context for AI today, it reminds me of software development before version control, code review, automated testing, and structured release processes became standard.

The Software Development Lifecycle connected those practices into a repeatable process, allowing developers to change software while preserving ownership, history, testing, and release controls. Companies need comparable discipline for context, including a consistent process for deciding who owns a definition, how someone changes it, who reviews the change, how applications test it, and how the new version reaches every system that needs it.

Enterprise AI needs a Context Development Lifecycle

I don’t think this requires inventing an entirely new set of enterprise processes. Much of the work already happens somewhere inside most companies, but today it happens separately. A Context Development Lifecycle can connect six activities: defining context, encoding it, reviewing it, testing it, publishing it, and keeping it current.

Business owners should define meaning within their domains. Finance owns financial definitions, legal owns the interpretation of policies, product owns relationships between products and capabilities, and support owns operating procedures.

Data and engineering organizations can then encode those definitions so applications consume them consistently. The representation will vary, but applications should draw from the same definition instead of translating it independently.

Then you have to decide who gets to change that context and who needs to approve it. Security can control access to sensitive information, legal and compliance can review regulated material, and domain owners can approve changes within their areas.

Application owners should test proposed changes against situations their systems encounter. If legal changes a refund policy, support can run common customer scenarios and known exceptions against the new version. If finance changes its ARR definition, analytics owners can test representative questions and compare the output with finance’s intent.

Once context passes review and testing, the organization can publish a version with an owner, effective date, and change history. If an agent produces an unexpected answer three months later, someone should be able to trace which definition it used instead of digging through prompts and repositories hoping to reconstruct what happened.

Each stage should leave something concrete behind: an owned definition, a machine-readable representation, an approval record, a set of tests, a versioned release, and a record of subsequent changes.

The process starts again whenever the business changes, giving the company a history of its business knowledge alongside the systems that already preserve the history of its data and software.

The next stage of enterprise AI depends on managing context

Enterprises can already choose among several capable models based on cost, performance, or workload. A more capable model cannot resolve two conflicting definitions of ARR, determine which policy legal intended it to follow, or know that a product rule changed yesterday unless the organization gives it that information.

Companies already know how to answer basic questions about data, including where it came from, who can access it, when it changed, and which system owns it. I want us to be able to answer the same kinds of questions about context. Who defined this metric, when did the definition change, which policy did this agent use, who approved that version, and which applications depend on it?

A Context Development Lifecycle gives companies a way to answer those questions and keep AI applications aligned as the business evolves. Software engineering became dramatically more reliable once organizations developed disciplined ways to manage changing code. Enterprise AI needs the same rigor around business context because an AI application can only stay accurate for as long as its understanding of the business stays accurate.