Somebody has to keep it current as models, policies and business requirements change underneath it, and somebody has to decide when it retires. In most organizations the answer to who does that is nobody in particular, which is why prompts and agents built with real effort quietly go stale.

Saturday night at a social event, the conversation moved toward AI. A friend shared the work her organization's internal AI team has been doing on a sophisticated 40-page prompt.

I was impressed by the effort. Months of alignment, which is the slow work of defining on paper what they actually wanted AI to do. The familiar back-and-forth between IT and the business about scope. A running argument about token cost, built on the theory that more instructions means more tokens means more expense, with nobody producing any actual numbers.

Then I asked what happens to the prompt after the next model release.

Nobody had thought about it. Not out of carelessness, but because that job hadn't been given to a person.

So that's what I want to talk about today. We're in the Wild West of agentic AI, and almost every conversation I'm in is about building. Very few are about what happens next.

The jobs don't disappear, they move

In the early stretch of the hype cycle, the dominant image was of agents humming along in the background doing the work while the jobs quietly evaporated. Anyone who has spent time around automation knows better.

So where does the work go? Factory automation moved people into maintenance, controls engineering, and the trades that keep the lines running. Automating software deployment gave us site reliability engineering, platform engineering, and an entire discipline around observability.

With automation, the work shifts from doing the task toward building, monitoring, and maintaining the thing that does the task. That shift is where the jobs go, and it's where they're going again right now.

Which is why the history of software feels so relevant.

Software already had this reckoning

For computing's first two decades, software was close to an afterthought. It came bundled with wildly expensive hardware and got written for one-off use cases. You wrote the code, ran it, fixed what broke, and called it done, with requirements living in someone's head.

Because software was welded to the machine it ran on, replacing the hardware meant rewriting everything. Long-term maintenance barely existed as a concept. Decommissioning was equally simple. You stopped feeding the punched cards into the reader.

Then organizations started running payroll and inventory on these systems continuously, and the approach came apart. Applications became tangles nobody could read, where fixing one line broke three things elsewhere.

It came to a head in October 1968, when roughly fifty experts from a dozen countries met in Garmisch, Germany at a conference organized by the NATO Science Committee. They arrived expecting to compare notes and discovered they were all facing the same challenges. That conference gave us the term software engineering. Their report described large-scale software production as an unprofitable morass. IBM's OS/360 was the cautionary example, at more than five thousand person-years. 😱

What came out of it was the lifecycle itself. Requirements, design, build, test, deploy, maintain, retire. It looks obvious now. It wasn't obvious then.

Most maintenance was never about things breaking

Here's the finding that maps most directly onto agents.

In 1980, Bennet Lientz and Burton Swanson studied 487 data processing organizations. Maintenance was consuming roughly half the software budget, which surprised people. The breakdown should have surprised them more.

The largest category was perfective work, meaning requirements had changed. Next was adaptive, meaning the environment around the software had changed. Fixing actual defects was the smallest slice of the three.

Most maintenance responded to change rather than breakage. The software was doing exactly what it was told to do. The world moved.

Now think about that 40-page prompt. Vendors expand model capabilities through routine platform releases without triggering any review on your side, so an agent you released last quarter can produce fundamentally different output today. Policies get revised. Approval thresholds move. Someone in legal updates a standard that three agents quietly rely on.

None of that is a defect. All of it needs a human deciding what changed and what to do about it.

And there's a question almost nobody is asking yet. When has an agent outlived its usefulness? I haven't met anyone with a decommissioning plan.

Two ways this goes wrong

The first is set it and forget it. A team invests months getting the instructions right, ships, and moves on. The artifact was hard to make, so it feels durable. Nothing seems wrong today. There's a quiet assumption that AI will somehow keep itself current.

The second is the failure to name an owner. Who owns the ongoing maintenance of that prompt? The team that benefits from it? The IT-based AI group? Both? Without someone named, with real responsibility for monitoring drift and evolving the instructions as models and requirements change, the prompt goes stale on its own.

Part of why this is so easy to miss is how many hands touch one agent. A business person writes the directives, somebody else uploads the knowledge, IT configures which systems it can reach, and a vendor updates the underlying model on a schedule you don't control. Everyone does their part well. Nobody is accountable for the whole.

Who owns the agent development lifecycle?

Salesforce put a stake in the ground with their version of an Agent Development Lifecycle, complete with role names like Agent Supervisor and AI Ops Manager. I think they are directionally right, and I would push the question further than the tooling vendors will, because the hard part here lives in the org chart rather than the diagram.

Who builds the instructions? Who revises them, on what cadence, with what authority? Who tracks model releases and translates what changed into implications for the instructions you depend on? Who watches for drift? Who monitors output for small deviations that look like nothing individually and compound into something material over two quarters? Who decides an agent should be retired, and cleans up the integrations and permissions it leaves behind?

In most organizations the answer to every one of those is nobody in particular.

The numbers on ownership

Earlier this year the Cloud Security Alliance surveyed 445 IT and security professionals about agents in production.

Seventy-four percent expect more than a hundred agents going live by the end of 2026. Only 15% have defined ownership for most of the agents they already have.

We're deploying at a pace that assumes somebody is minding the store. In most organizations, who has actually been told that's their job?

This is human infrastructure

We're so busy talking about the jobs going away that we're missing the ones being created. This is one of them.

It's the kind of human infrastructure I argue for in Hyperadaptive. Named people, or named structures like an AI Activation Hub, responsible for staying current on model releases, translating what changed into something the organization can use, and maintaining the policy and pattern library that keeps everyone's instructions aligned. As knowledge spreads, AI leads shift from teaching people how to build agents toward keeping track of them. The AI Telemetry Network is where monitoring lives.

None of that requires new headcount, which I know is the first place the conversation goes. What it requires is named accountability.

It took the software industry a crisis and a decade to learn that shipping is the front end of a much larger lifecycle. We already know that, and we're currently choosing not to apply it.

I'm oh-so-curious. Who in your organization owns the agent lifecycle, and does that person know it?

Sources and further reading

NATO Software Engineering Conference report, Garmisch 1968, edited by Peter Naur and Brian Randell.
Problems in Application Software Maintenance, Lientz and Swanson, Communications of the ACM, on the 487-organization study.
Enterprise AI Security Starts with AI Agents, Cloud Security Alliance, April 2026: survey of 445 IT and security professionals.
8 Ways AI Agents Are Evolving in 2026, Salesforce, on the Agent Development Lifecycle.
AI Agent Governance: Complete Guide for Security Teams, on silent vendor updates and drift.

What has to happen to an AI agent after you build it?