Why do in-house AI tools quietly stop working, even when nobody changed the code?

This explores why AI tools that organizations build for themselves tend to decay or get harder to keep working after launch. The library has no study of internal-tool maintenance directly. What it does have, from several directions, is a fairly clear explanation: AI tools are built on materials that don't hold still, and most maintenance habits assume they do.

The first problem is the materials themselves. Ordinary software runs on fixed logic and a stable interface, so once something works it tends to keep working. An AI tool depends on its prompt, the conversation history, whatever data gets retrieved and hidden model state, and all of these keep changing. How does AI context differ from conventional software context? argues this calls for a new discipline, context engineering, in place of interface design. A related note goes further: AI output changes with sampling, wording and audience by its nature. That isn't a bug to fix, and it means traditional quality assurance doesn't fully apply (Why does AI output change with every prompt and context?). An internal tool that passed its tests last quarter has no guarantee of behaving the same way now.

The second problem is quieter: tools decay as people fix them. Every time a team rewrites a prompt or squeezes its instructions down to fit, hard-won details get lost. One study names this "context collapse" and "brevity bias." Its proposed fix is to treat the context as an evolving playbook that is updated in small steps and curated, never wholesale rewritten (Can context playbooks prevent knowledge loss during iteration?). The same idea appears in agent research. Agents that keep skills in an external, composable library keep learning without forgetting old skills, which retraining the model's weights does not achieve (Can agents learn new skills without forgetting old ones?). Agents that work inside changing software stay useful by combining fresh outside knowledge with layered memories of past tasks (How can GUI agents adapt when software constantly changes?). For anyone maintaining an internal tool, the shared lesson is that its accumulated knowledge needs to live somewhere structured and versioned. Kept in one ever-growing prompt, it erodes.

The third problem is human. AI-generated code and output can look right while hiding small errors. Stack Overflow's 2025 survey found developer trust falling while usage rose, because checking the output is a constant burden (Why do developers keep using AI tools they don't trust?). It gets worse when builders overrate how well they understand what they built. Unclear authorship, fluent output, outsourced thinking and a pipeline nobody can see into all combine to make people credit themselves with competence that belongs to the AI (How do AI tools trick users into overestimating their own skills?). An internal tool built quickly with AI help can leave behind a maintainer who doesn't really know how it works.

The point you may not have expected: making tools easier to build can make the maintenance problem worse. Benedict Evans argues that lowering coding friction doesn't solve the real barriers, which are recognizing what's worth automating and getting decisions made across departments (Does easier tool-building actually solve enterprise adoption problems?). Cheap creation produces many small tools, each sitting on shifting context, each owned by someone who may not fully understand it, and few of them owned by the organization as a whole. The library's evidence points to ownership and curation as the scarce resource, more than engineering effort.