The Agent Cleanup: What Should Have Been Built Instead
Open LinkedIn on any given morning and count the posts about AI agents. Agentic workflows. Agentic commerce. Multi-agent orchestration. Agent swarms. The vocabulary is everywhere, the implementations are multiplying, and the promise is consistent: agents will transform your business.
What follows is predictable. Within 18 to 24 months, a significant number of organisations will be quietly decommissioning agents that cost more to maintain than the value they produce.
But this piece isn't about pointing at the problem. It's about what should be built instead.
What's actually being deployed
Before discussing alternatives, it's worth being precise about what most "agent" implementations actually look like in practice.
The architecture typically follows this pattern: an existing system generates data or a trigger. That trigger calls an orchestration layer. The orchestration layer sends a prompt to an LLM API. The LLM returns text. A parsing layer extracts structured data from that text. A validation layer checks the output. A transformation layer reformats it for the target system. The target system receives the data.
That's six new layers inserted between two systems that previously communicated directly. Each layer adds latency, maintenance surface, and failure risk. And the LLM step in the middle introduces something that didn't exist before in the integration chain: non-determinism. The same input can produce different output on different days, because the model provider updates the model without notice, or because the prompt hits a slightly different token path.
For some use cases, this architecture makes sense. For the majority of what's being implemented today, an honest assessment would conclude that a well-designed script with conditional logic would produce identical results — faster, cheaper, and deterministically.
This isn't a theoretical concern. It's a maintenance and debugging reality. When a production incident occurs in a traditional integration, the root cause is traceable: a value changed, a service timed out, a schema was modified. When a production incident occurs in an agent pipeline, the root cause might be that the LLM interpreted a prompt differently today than yesterday. Diagnosing that is a fundamentally different — and significantly harder — challenge.
The cleanup that's coming
The pattern is predictable because it has precedents.
Microservices went through the same cycle. Organisations decomposed monoliths into hundreds of services, discovered that the orchestration complexity exceeded the original problem, and spent years consolidating back toward rational service boundaries. The technology wasn't wrong. The application was indiscriminate.
Cloud migration had its own correction. Lift-and-shift projects that moved applications to cloud without re-architecture ended up costing more than the on-premise infrastructure they replaced. The technology wasn't wrong. The assumption that moving was inherently better was wrong.
Agent implementations will follow the same arc. Not because agents as a concept are flawed, but because the deployment criterion in most organisations isn't "does this problem genuinely require autonomous reasoning?" It's "can we put an agent on this?"
The difference between those two questions is the difference between engineering and marketing.
Where AI actually transforms — without agents
Here's where this analysis becomes constructive. The most valuable applications of AI in enterprise environments often don't involve agents at all. They involve using AI capabilities precisely where they solve problems that couldn't be solved before — or that were prohibitively expensive to solve with traditional approaches.
1. Institutional knowledge rescue
Every enterprise has critical knowledge trapped in the heads of people approaching retirement, buried in undocumented code, or scattered across years of email threads and incident reports that will likely never be read again.
AI is genuinely transformative here — not as an agent that makes decisions, but as a tool that extracts, structures, and makes searchable the knowledge that would otherwise walk out the door.
The practical implementation: feed historical incident reports, runbooks, architecture documents, and code comments into a retrieval system. Not to make autonomous decisions — to make the organisation's own knowledge accessible to the people who need it. When a junior engineer faces an incident at 2 AM, the difference between having the organisation's collective experience searchable and having nothing is measured in hours of downtime.
No agent required. A well-implemented RAG system with proper indexing does this better, faster, and more reliably than any autonomous agent.
2. Documentation generation from reality
The number one complaint in every enterprise I've worked in: documentation doesn't exist, is outdated, or was written by someone who didn't understand the system.
AI can reverse-engineer documentation from code, configuration files, and system behaviour. Not perfect documentation — but documentation that's 70% accurate is infinitely more valuable than documentation that doesn't exist. A human reviews, corrects, and approves. The AI did the heavy lifting that was perpetually deferred — not from laziness, but from competing priorities.
This is exactly the pattern DiagnosticMind operationalises. AI does the extraction and structuring. The human with domain expertise does the validation and correction. The result is documentation that actually reflects the system as it exists today, not as it was designed five years ago.
No agent required. A well-prompted LLM with access to the right source material produces this in hours instead of weeks.
3. Diagnostic assistance — the intelligent second opinion
When a production incident occurs, the first 15 minutes determine whether it's resolved quickly or escalates into a multi-hour crisis. The bottleneck is usually not access to data — it's interpretation. The monitoring dashboard shows 47 alerts. Which one matters? Which ones are symptoms and which is the cause?
AI can serve as a diagnostic assistant that correlates alerts, suggests probable root causes based on historical patterns, and highlights the signal in the noise. Not making decisions — presenting analysis that helps the human make better decisions faster.
This works when it's implemented as a tool that the engineer consults, not as an agent that takes autonomous action on production systems. The distinction matters enormously: a tool that suggests "based on historical patterns, this combination of alerts typically indicates a database connection pool exhaustion" is valuable. An agent that autonomously restarts services based on that analysis is dangerous.
No agent required. Pattern matching against historical incident data with an LLM providing natural language interpretation.
4. Intelligent triage and routing
Support tickets, change requests, incident reports — every enterprise processes thousands of these, and the routing is usually based on simple keyword matching or manual assignment. The result: tickets land in the wrong queue, get bounced between teams, and resolution time inflates.
AI can genuinely improve this by interpreting the intent and technical content of a request and routing it to the right team with the right priority. Not because it understands the technical domain deeply — but because it can parse natural language better than any keyword-based system.
This is one of the few areas where calling it an "agent" is arguably fair — it's interpreting ambiguous input and making a routing decision. But the implementation should be narrow, well-bounded, and have a human override. The moment it starts making resolution decisions instead of routing decisions, the risk profile changes dramatically.
5. Competence assessment — measuring what matters
This is where the industry has an almost complete gap. Organisations spend billions on training, certification, and professional development — and measure the result by attendance. Did they complete the course? Check. Did they watch the webinar? Check. Can they actually apply what they supposedly learned? That part rarely gets measured.
AI makes scenario-based competence assessment economically viable for the first time. Present a professional with a realistic situation, evaluate their reasoning through a series of adaptive decision points, and produce an evidence-based assessment of demonstrated capability. Not a multiple-choice test — a diagnostic simulation that measures thinking.
No agent required. An adaptive scenario engine with AI-powered evaluation of responses.
The decision framework: agent, tool, or script?
Before implementing any AI-powered solution, three questions cut through the hype:
"Does this problem require autonomous reasoning about ambiguous, unpredictable situations?"
If yes — genuine agent territory. Customer service for complex, multi-step inquiries with unpredictable paths. Real-time negotiation where the parameters change dynamically. These are legitimate use cases, and they're rarer than the market suggests.
If no — don't build an agent. Build a tool or a script.
"What happens when the AI produces an incorrect output?"
If the consequence is minor — a slightly wrong email draft, a suboptimal ticket routing that gets corrected by a human — the risk is acceptable. Deploy, monitor, iterate.
If the consequence is significant — a wrong transaction, a production change, a compliance decision — the AI should inform, not act. Human in the loop isn't a limitation. It's the engineering decision that keeps the system safe.
"Could a well-designed script with conditional logic produce the same result?"
Be honest. If the answer is yes, build the script. It will be faster, cheaper, deterministic, debuggable, and maintainable. The LLM adds value only when the input is genuinely ambiguous or unstructured in ways that conditional logic can't handle.
The takeaway
The organisations that will extract real, lasting value from AI in the next three years won't be the ones with the most agents. They'll be the ones that applied AI precisely where it solves problems that couldn't be solved before — knowledge rescue, documentation from reality, diagnostic assistance, intelligent triage, and competence verification — while keeping traditional automation for everything that traditional automation handles perfectly well.
The agent cleanup is coming. The question for every organisation is whether they'll be dismantling failed experiments or building on solid foundations.
The technology isn't wrong. The application matters. And knowing the difference between "this needs AI" and "this needs a script" might be the most valuable diagnostic skill in enterprise IT right now.