What Most Organizations are Missing in the Rush to Build Agents
We're in the Wild West of Agentic AI, and We Need to Think Beyond Building
Saturday night at a social event, the conversation moved toward AI. A friend shared the work she was doing with her organization’s internal AI team on a sophisticated 40-page prompt.
I was impressed by the effort and the level of sophistication, and surprised by how much of it was going into alignment, which is the slow work of defining on paper what they wanted AI to do. There was the familiar back-and-forth between IT and the business about scope, and 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. (There is a whole article on how confidently we reason about AI costs without data, and another one on the power struggles running underneath these projects. Both for another week.)
I didn’t hear anything about what happens to the prompt next month, or after the next model release, or when the AI policy gets revised by someone who has no idea her prompt even exists.
So, that’s what I want to talk about today. The prompts, the automations, and the agents being built…then being put on a shelf.
Agentic AI Goes Beyond Building
In the early stretch of the AI 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. Factory automation moved people into maintenance, controls engineering, and 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, and that shift is where the jobs go.
Which is why the history of software feels so relevant right now.
What Happened in the Early Days of Coding
In the 1940s - 1960s, software was often an afterthought, bundled with wildly expensive hardware and written for one-off use cases. The mindset it produced was reasonable at the time:
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 specific machine it ran on, replacing the hardware meant rewriting everything, so long-term maintenance barely existed as a concept. Decommissioning was equally simple, since you just 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 for a conference organized by the NATO Science Committee. They arrived expecting to compare notes and discovered they were all facing the same challenges. The conference gave us the term ‘software engineering’ and articulated a clear gap in software development. Their report is remarkably blunt, saying that large-scale software production was “an unprofitable morass, costly and unending.” IBM’s OS/360 was the cautionary example, at more than five thousand person-years. 😱
The outcome of their meeting was the software development lifecycle itself. Requirements, design, build, test, deploy, maintain, retire. It looks obvious now. It was not obvious then, and it took an international cohort to surface it.
Maintenance is Predictable…and Human
In 1980, Bennet Lientz and Burton Swanson published a study of 487 data processing organizations. Maintenance was consuming roughly half the software budget, which surprised people. What should have surprised them more was the breakdown:
The largest category was perfective work, meaning requirements had changed.
Next was adaptive, meaning the surrounding environment had changed.
Fixing actual defects was the smallest slice of the three.
Most maintenance was a response to changes happening underneath software that was working exactly as specified.
Now think about a 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, and someone in legal updates a standard three agents rely on. None of that is a defect. It is adaptive and perfective maintenance that needs a human telling AI what changed and what to do next.
There is one other challenge. When has an agent outlived its usefulness? Nobody I talk to has a decommissioning plan for an agent.
The Two Failure Modes I am Seeing
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, and nobody schedules a review. Nothing feels wrong with it today. It feels like AI will make its own updates. We are back to the early days of software engineering, where it feels easier to fix the software as-needed than plan for it to break.
The second is the failure to name an owner. In our example above, who owns the ongoing maintenance of that prompt? The group that is the beneficiary of the prompt? The IT-based AI-group? Both of them? Without a named owner with clear responsibilities tied to monitoring drift, evolving the prompt as models evolve, and tracking changing customer and business requirements, the prompt grows stale.
AI needs a human to tell it when to update its instructions. When something is wrong. What it needs to improve. In short, the world around the agent changes and yet it keeps doing the same thing it did yesterday.
Who Owns the Agent Development Lifecycle (ADLC)?
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. 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.
Part of why there is no owner 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 do not control. Everyone did their part without naming a person accountable for managing the maintenance.
This Is the Human Infrastructure Part
We are so busy talking about jobs going away that we forget to talk about the jobs being created. This is one of them. We need a named person with a named responsibility to take on the ADLC.
This is the type of human infrastructure I argue for in Hyperadaptive. Named people or structures (like an AI Activation Hub) who are 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, your AI Leads shift from training people on how to create agents, to 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 does require 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 have the advantage of already knowing that, and we are currently choosing not to apply it.
I’m oh-so-curious. Who in your organization owns the agent lifecycle?
Take Action: Learn How to Bring Human Infrastructure to Your Organization
We work through this kind of operating discipline in the upcoming course Running Hyperadaptive Organizations. The next cohort meets August 11 and 18. Details here.
Sources & 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)
Bang on, Melissa! Might I add, managing Agents as a Service (IT Service Management) would look at it from a Lifecycle perspective (Discover, Design, Acquire, Build, Transition, Operate, Deliver, Support, per ITIL v5)