Why production changes the problem

A capability becomes a service commitment

During exploration, a team can prepare an input, observe the result, and adjust the experiment. In operation, that sequence sits alongside pending work, deadlines, and people who are not taking part in a test.

The question changes from “Can it do this?” to “What can we expect from it?” The answer needs to describe supported uses and service conditions: accepted inputs, how long an outcome may take, and what happens to work that cannot be completed.

Perfection is not the requirement. Expectations must be compatible with what the system can sustain. If a tool is supported only during certain hours, its operation should reflect that. If outputs require review before use, review is part of the service.

Reliability engineering distinguishes service indicators from objectives set for those indicators. Google's SRE book uses that distinction to connect observable measures with the behavior a service is intended to provide. The idea can be useful without adopting Google's scale or organizational structure.

For an AI system, application availability does not describe the whole experience. A service may respond while producing outputs that no longer support the work. Its commitment must consider output usefulness and the stages that make that output usable.

Defining the commitment prevents each user from inventing a different interpretation of “working.” It also supports decisions about which problems need immediate attention and which can wait without undermining the intended use. A technical status alone cannot settle that priority.

The environment is no longer controlled

In production, the application shares an environment with systems and people that continue to change. A source responds more slowly, an input arrives incomplete, or a team changes how it records information. Those variations become part of the problem.

Dependencies can fail visibly, but they can also remain available while changing behavior. An integration may return valid data with a different meaning. Search may still retrieve documents while missing the material needed for a new class of query.

Load involves more than total volume. Arrival patterns, time per case, and shared resources matter. A test spread across a day may not represent several requests arriving together just before a deadline.

The design must identify which dependencies constrain the service commitment and what room exists when they stop meeting it. Some delays allow waiting. Others require limiting incoming work or explaining that the outcome will not arrive under the expected conditions.

Anticipating every combination is unnecessary. The essential conditions for operation should not remain hidden in the experience of the person who built the prototype. What was obvious to that person needs to become information others can consult and use.

A manageable service makes its critical dependencies visible. That visibility helps interpret problems and prevents every change in quality or response time from being attributed to the model. It also turns a vague report that the application feels different into questions about identifiable parts of the service.

A version is more than the model

An AI application's behavior depends on a combined configuration. The model participates, along with instructions, tools, sources, and the rules connecting its outputs to the rest of the work.

Recording only the model name therefore leaves an incomplete account of what is being operated. Two executions can use the same inference version and behave differently because a reference document, integration function, or acceptance condition has changed.

The organization should be able to identify which combination of components was active when a relevant outcome occurred. This does not require retaining all data indefinitely. It requires enough traceability to interpret a change or investigate an incident.

Hidden Technical Debt in Machine Learning Systems, published in 2015, examined maintenance risks involving data dependencies, configuration, and changes in the environment. It concerned machine learning systems rather than today's agents. The relevant observation is that the unit needing maintenance extends beyond the model.

This changes how improvements should be introduced. An apparently small modification can alter an important relationship. Changing a tool description may change how the tool is used. Updating a source can change which answers are considered correct.

Freezing the system is not the answer. The answer is to preserve a relationship between changes, checks, and decisions to put those changes into service. An operationally useful version record explains what changed and why using that configuration is considered acceptable, rather than merely naming its most visible component.

Continuity can take different forms

When part of the system fails, preserving identical behavior at any cost is not always appropriate. Continuity may mean a narrower service, retained pending work, or a suspended function until its necessary conditions return.

The choice depends on use. One application may keep preparing drafts while an auxiliary source is unavailable, provided the limitation is visible and the result remains useful. Another must stop because that source determines a condition essential for acting.

Degradation should not mean silently replacing verified information with a plausible response. Reduced capability must be recognizable to the recipient and consistent with the commitments still in force.

A manual alternative also requires design. If it is the continuity path, someone must know who performs the work, what information they receive, and how much volume they can handle. Calling an option manual does not create the capacity to operate it.

Restoring normal service introduces another decision. Accumulated requests may no longer be relevant, approvals may have expired, or actions may have been performed through another route. Resuming everything without checking those conditions can create new problems.

Returning to an earlier version is also different from reversing its effects. Restoring a configuration does not automatically remove changes that version made elsewhere. Recovering the service and correcting affected work may require different actions.

Continuity is easier to design when the organization specifies what each response preserves: information, reviewability, work order, or a minimum outcome. That definition allows service to be reduced without losing control over what continues to happen.

Operation consumes organizational capacity

System cost extends beyond infrastructure and model calls. It includes time spent handling incidents, reviewing outputs, maintaining sources, and adapting integrations as work changes.

These activities do not necessarily indicate a poor solution. Some belong to any useful service. The questions are whether they are anticipated, whether capacity exists to perform them, and whether the resulting value justifies that effort.

Automation can remove repetitive work while creating a new supervision requirement. Its contribution can only be understood by observing both. If follow-up always depends on the original developer, an operational dependency may exist that the initial delivery did not make visible.

Service ownership should be recognizable. Someone decides scope, someone attends to operation, and someone can authorize changes. In a small team, one person may hold several responsibilities. What matters is that the responsibilities do not disappear because there is no formal organizational structure around them.

Documentation should support those functions. A lengthy component description may be less useful than instructions for recognizing an interruption, finding the current state, and identifying who makes the next decision. Technical information remains necessary, but it should connect to the action it enables.

Operating cost should also be revisited. Usage can grow, change character, or require more intervention than expected. Maintaining the solution means reconsidering whether its scope and commitments remain appropriate. The initial design is a decision made under particular conditions, not a permanent exemption from further judgment.

Rigor should match the dependency created

Thinking about production does not mean building complex infrastructure for every application. A low-impact internal aid may operate with simple controls when its limits are clear and people can continue working without it.

The criterion should be the consequences of interruption, the difficulty of recovering work, and the dependency being created. Copying the architecture of a much larger service does not establish that relationship.

Proportionality applies to promises as well as controls. Continuous availability should not be offered when the organization cannot support it. Equally, a change procedure should not become so burdensome that a modest tool can no longer be maintained.

Scope can expand gradually. A limited initial operation can reveal actual needs and allow adjustment before other activities become dependent. But that limitation must remain visible. Calling something a pilot while using it as a general service does not reduce its consequences.

Leaving production is part of the lifecycle too. A solution may cease to provide value, be replaced, or need a pause. Retiring it requires understanding dependent work, information that must be retained, and how activity will transfer elsewhere.

Production introduces responsibility for the system's evolution as a whole. Engineering does not end when a capability becomes accessible. It continues while that capability supports work the organization needs to perform, and includes the decision to stop supporting it when its role no longer makes sense.

This lifecycle view also changes the meaning of handover. Delivering a working application is only one part of transferring a service into regular use. The organization needs to know which conditions support it, who acts when those conditions fail, and what can be expected while they are restored. Without that understanding, the service commitment remains implicit even if every component has been documented.

The appropriate response can remain simple. What matters is that someone can make the next decision using information the system preserves, rather than depending on the original developer to reconstruct the situation. That is how a technical capability becomes a service the organization can understand, maintain, and eventually replace. The level of formality can vary; the need for an accountable response remains.