“Agents” are just a band-aid for bad architecture

Hardly a day goes by without someone announcing how agents solve steps that used to be manual or took a lot of (unnecessary) work.

Plot twist: most of them aren't even agents. Reading an invoice image with AI, automatic checking, payment and creating the supplier don't make it an “agent”, not even together. If the steps are known in advance, it's automation, possibly with AI somewhere in between. It only becomes an agent when the AI decides its next step itself, based on the previous result, and calls the right tools to solve the problem.

Agents are often used to patch technical debt built up over the years. Solutions that are often duct tape on top of duct tape. The whole has become so complex that only an agent can help anymore. Up to a point.

If there's no duct tape and everything could be built from a clean slate, the need for agents stays small. In good architecture there are so few steps and the database is so solid that most things are solved with traditional rules and automation, without AI having to gamble on probabilities.

Then there are the real agents. An agent fetches stock levels from one system, purchases from another and the production plan from Excel, works out a material shortage, proposes purchases and reschedules production. That really is an agent, because every time it has to figure out where the information is and which number is correct.

But it's an agent that should never be needed. In a single data model, the same thing is basic MRP logic and rules. Bad architecture turns a simple problem into one that only an agent can solve.

90% of a system should be solved by architecture, and the remaining 10% by smarter use of AI.

At Erpitect we're building an AI-native ERP for manufacturing from a clean slate, on a metadata-driven foundation. I asked Claude to go through our product and look for places where agents would add value. It suggested five. On a closer look, four of them were automation with AI in between, or interfaces the architecture already supports. They fit straight into our existing task engine without a single agent.

There was only one actual agent: analysis, when someone asks, for example, “why did the margin drop 10% last quarter”. There the next query always depends on the result of the previous one, so there is a real need for an agent. The architecture already handles everything else, deterministically and without relying on probabilities.

In Claude's words:

Much of the agent hype comes down to patching a missing workflow engine with an LLM loop.

Often that 90/10 seems to be the other way round, once the ERP has become just a “data store”. I'm curious to see what costs and security problems are still ahead as architectures get spread across scattered MCP integrations and agents, or all data is handed blindly to AI services.

And no, MCP isn't the problem either. The problem is that it's used to glue together systems that should have been one in the first place. Eventually you hit the limits, technical or financial, and customers are forced to replace the core as well, to get rid of unnecessary agents and the slowness and costs that come with them.

So the essential question is this: does the need for an agent really come from the nature of the problem, or from the system's own architecture forcing AI to work out things it should already know?

And how did that one real agent turn out for us? Building it on top of a single data model was almost trivial. All the tools already existed, so the agent only has to decide in which order to use them. The principle is the same as everywhere we use AI, though. The AI never gets a connection to the database and is never allowed to browse data freely. It directs the ERP to fetch the right things, and the ERP decides what is run and who sees the result. This is where agent solutions almost always fall short, when the AI is handed everything possible, down to personal ID numbers.

Our solution is an example of how an AI-native ERP doesn't mean using as little AI as possible. It means an ERP whose architecture was designed from the start to use AI smartly and in a controlled way. An environment where AI can work easily, and that doesn't go dark even if AI services ended today.

Next time you hear how agents make things easier, ask two things. Is it really an agent? And if it is, does it fix a business problem, or does it just patch bad architecture?