AI initiatives rarely fail during the demo. They fail in the first 90 days of production.
The pattern is familiar: a small team builds something impressive, leadership leans in, and the conversation shifts to, “How quickly can we get this into production?”
The answer is almost always longer than anyone wants to hear — not because the technology is immature, but because the gap between a working demo and a production system is fundamentally an operating-model problem, not merely an application-engineering one.
A successful prototype proves a model can perform a task under favorable conditions. It does not prove the system can do it reliably at scale, within cost constraints, on current and authorized data, through tools with real side effects, and with teams that can detect and reverse failure.
LLMOps remains necessary: prompts, models, evaluation datasets, deployments, and inference all need disciplined operations. But LLMOps is now one layer of a broader AI platform. Production systems also have context pipelines, agent runtimes, delegated identities, and persistent memory. Operating only the model leaves the rest of the system unmanaged.
What follows is the operating model required to close that gap — the shared capabilities product teams should not have to rebuild every time they move a prototype into production. Each section states the decision a leader has to make; the complete control set behind it is on the AI platform capability checklist.
1. Evaluate the system, not only the answer
Prototypes are evaluated by vibes — “it looks right,” but production systems require automated, repeatable evaluation tied to business metrics.
This means defining “good” at every layer that can fail independently, which differs by system type: retrieval quality and authorization correctness for RAG systems, task completion and path quality for agents, and for user-facing systems whether the business outcome improved without creating unacceptable harm or operational load.
A final answer can be correct even though the agent reached it through a risky or expensive path. A fast retrieval result can be useless because the source was stale or not authorized for the user. Production evaluation therefore has to cover the trajectory — the context selected, the tools used, and the cost incurred getting there — not only the final text.
The evaluation framework should be in place before deployment. Every meaningful change to a model, prompt, tool, context pipeline, or policy should run against an appropriate regression set before staged rollout. Production feedback then adds new failure cases to that set. Without this loop, teams debug incidents with no baseline and repeat the same failures in different forms.
2. Context and knowledge need a lifecycle
In prototypes, context is a folder of documents or a convenient database dump. In production, context is part of the product’s decision surface. What the system knows, when it learned it, who may use it, and when it must forget it all affect the answer.
A shared context platform should make these stages explicit:
- Ingestion: approved sources, parsers per source type, and validation before content becomes retrievable.
- Freshness: update expectations set per source, failed-sync monitoring, and age visible at retrieval time.
- Authorization: permissions enforced during retrieval using the requesting user’s or workload’s entitlement — not hidden in a prompt and not applied only after content has reached the model.
- Provenance: source identifiers, versions, and transformation history carried into traces and user-visible citations.
- Deletion: a reliable path from removal at the source through indexes, caches, and every derived representation that can still return it.
Context quality is not a one-time data-engineering project. It is an operational service with owners, objectives, and failure modes. The technical patterns are covered in more depth in the breakdown of retrieval component decisions; the platform requirement is that every product team receives these lifecycle controls by default.
3. Agents and tools need a control plane
A tool connected during a prototype is usually a function in the application. At platform scale, tools are shared capabilities with authority: send a message, deploy code, or initiate a financial action. Agents combine those capabilities dynamically and may hand work to other agents. That demands a lifecycle beyond deployment.
The control plane should support:
- Registration and ownership: what the agent or tool does, who owns it, and who responds when it fails.
- Approval: risk-based review before a capability is exposed, covering authorization, side effects, and human-confirmation requirements.
- Versioning: stable contracts, evaluation evidence, and staged adoption when schemas, models, or behavior change.
- Capability-change review: renewed approval when a read-only tool gains write access, an agent gains another tool, or an inter-agent connection changes the reachable trust boundary.
- Retirement: revoking credentials, migrating dependents, and retaining the audit history required to explain earlier actions.
Protocols such as MCP make capability discovery and integration easier, but compatibility is not approval. The platform still decides which server, agent, and task may cross each boundary. The same principle applies to the broader production-agent operating model: interoperability connects systems; policy determines trust.
4. Identity, delegation, and memory are platform services
An agent acting on someone’s behalf needs a workload identity of its own, with short-lived credentials scoped to the task in front of it. The delegation it carries has to preserve who initiated the work, what was approved, and when that authority expires — enforced by the tool at execution time rather than assumed from the fact that the call arrived. Persistent memory sits in the same tier for a related reason, since a stored fact creates a durable data boundary that outlives the invocation which produced it and inherits the same obligations around retention and audit.
The full control set for both is worked through in the agent identity and memory controls that hold up in production, which leaves the platform with the narrower and more consequential question of ownership. However strong the individual product teams are, a delegation format and a memory governance policy designed independently in five places will diverge in five defensible directions, and that divergence usually comes to light in an audit, long after the decisions that caused it. Therefore the delegation contract, the credential lifetime, and the tenant isolation boundary should be platform property, handed to teams as settled ground.
5. Observability must follow the whole transaction
Production AI systems usually degrade quietly, and the traditional service signals — latency, errors, saturation, and uptime — remain necessary without ever becoming sufficient, because none of them can explain why an agent selected a particular tool or where a multi-step task spent its budget. Therefore the unit of observation has to be the transaction rather than the service. What that requires is a single trace following one request the whole way through, from the gateway and the retrieval it triggers to the tool executions and the outcome finally delivered to the user.
The trace schema and the content-governance rules that accompany it are set out in the minimum useful trace for an agent invocation, and standardizing on the OpenTelemetry semantic conventions keeps that telemetry portable as model and agent frameworks change underneath it. Additionally, the instrumentation itself belongs to the platform, since a trace earns its cost only when it is complete, and completeness across a transaction that crosses four teams is not something any single service along the path can deliver on its own. Detecting degradation before users report it is only the floor; the real objective is to connect a quality or policy failure to the exact model version, context source, and rollout that produced it, which is the resolution a trace has to support.
6. Routing and budgets are measured controls
A prototype runs on a single model, almost always the most capable one available, which is the right call when the only question is whether the task can be performed at all. Production changes the question and the economics with it. Systems at scale route by task complexity, risk, and cost, caching wherever the semantics allow it, and they need a defined escalation path to a human for the cases where confidence or authority falls short of what the decision requires.
Routing does reduce cost, however no universal savings percentage exists to plan against, because the outcome depends on workload mix, model pricing, and the quality threshold the business is prepared to hold. Therefore a routing change is an experiment with a predicted result and a measurement to confirm it, and it counts as successful only when the evaluation suite demonstrates that it moved the intended cost or latency measure without unacceptable regressions for the affected task segments.
Budgets belong in the same tier of controls and answer to the same standard of evidence, since runtime-enforced limits are what convert agent spend from a variable into a forecastable line item. The specific limits worth enforcing, and the compounding factors that make agent cost the failure mode nobody gets paged for, are developed in the production-agent reliability guide.
7. Rollback is a platform capability
AI behavior is distributed across components, so rollback cannot mean only “switch back to the previous model.” Prompts, retrieval configurations, policies, and agent graphs all shape behavior independently, which means each needs a version that can be reverted without reverting the others. The components that need independent rollback, and the release mechanics around them, are set out on the checklist.
The leadership decision is narrower than the mechanics. Operators need kill switches that can disable a single agent or model route without taking down unrelated products, and someone has to hold the authority to pull one. For consequential systems, exercise those switches on a schedule and time the result, because an emergency control that has never been used has an unknown recovery time and is therefore an assumption rather than a capability.
8. Governance is the paved road
Governance should not be a committee manually approving every low-risk experiment. It should turn organizational requirements into reusable paths: approved models and tools, automated evaluation and security gates, and audit data generated by the delivery workflow rather than assembled afterward.
- Risk-tiered approvals: the review required for a summarization tool should differ from the review required for an autonomous system taking external action.
- Continuous testing: safety, security, and robustness evaluation tied to the system’s context and impact, not completed once at launch.
- Auditability: who changed what, under which approval, when it reached users, and what measurable impact followed.
- Incident ownership: clear authority to contain, investigate, and correct downstream data.
The NIST AI Risk Management Framework remains a useful structure for this work through its Govern, Map, Measure, and Manage functions, alongside the Generative AI Profile. As of July 2026, NIST explicitly notes that AI RMF 1.0 is being revised, so organizations should track the revision and avoid freezing internal controls to the 2023 text.
Done well, governance accelerates delivery. Product teams move faster because approved components, automated controls, ownership, and evidence are already available. The alternative is not speed; it is every team rediscovering the same security, compliance, and operational requirements late in deployment. The questions that turn governance into an operating system are explored further in the AI governance field guide, while the adversarial validation layer is covered in the AI security testing guide.
The pattern that repeats
The transition is usually scoped as a “just ship it” problem — add error handling, raise the limits, call it production. That is a rational reading of the situation, because the prototype was approved as an application and the request on the table is to harden it. Nothing in that framing surfaces the platform layer, so nothing funds it.
Organizations that get through the first 90 days treat it as a platform problem instead: evaluation, context lifecycle, agent and tool controls, identity, memory, observability, rollback, and governance built as shared capabilities, alongside the system and well before it breaks. The difference is not how well the engineering was done. It is whether the second system was named and funded while there was still time to build it.
The technology works. The constraint is the operating model required to run it reliably — and that is a leadership decision, made before the prototype is handed over rather than during the incident that follows. LLMOps is part of the work, but the durable platform extends around the entire AI transaction: from the data entering context, to the authority behind an action, to the evidence retained after the outcome.
If your organization is moving from a working prototype to a production AI platform and needs an outside read on the operating model, I work with engineering leadership to build the evaluation, governance, and observability layers that make scaling possible. Get in touch.