The issue is not that agents are overhyped. The issue is that people are forgetting what they already knew about distributed systems.

Over the past two decades, we collectively agreed on a few basic principles in software architecture. Modular systems make change easier, loose coupling keeps components from holding each other hostage, and clear contracts reduce the kind of ambiguity that usually becomes expensive only after something has already reached production. Resilience is not an optional decoration you add when the demo already works, because state handling, retries, idempotency, observability, replayability, compensation logic and failure management are not exotic enterprise hobbies. They are the reason many systems survived contact with reality in the first place.

Then AI agents arrived, and somehow parts of the industry started behaving as if those rules had expired.

I do not have a personal problem with agents. If someone wants to spend a fortune in tokens to build a coffee maker agent, fine. It may not be the first use case I would fund, but that is not the point. The problem starts when agent platforms reintroduce brittle architecture through the backdoor and call it innovation.

Calling something an agent does not remove the need for control flow. It just hides the fact that you lost it.

We Solved a Lot of This Already

Software engineering already learned many of these lessons the hard way. We learned that tightly coupled systems are difficult to change. We learned that direct dependencies across too many components create fragile chains of failure. We learned that retries without idempotency can make a bad situation worse. We learned that state hidden inside black boxes becomes a debugging nightmare. We learned that systems without observability are not systems. They are acts of faith with a dashboard attached.

None of this is new.

Workflow engines, message brokers, queues, service discovery, event-driven architecture, orchestration frameworks and distributed transaction patterns did not appear because engineers were bored. They appeared because real systems fail in boring, expensive and deeply inconvenient ways.

A network call fails, a service times out, or a downstream system accepts a request but never sends the response. A customer sends the same message twice, a batch arrives late, a message is processed more than once, or a database commit succeeds while the follow-up action fails somewhere else. Sometimes the system crashes exactly between two steps where the architecture diagram had a clean arrow, a confident label, and absolutely no opinion about what should happen when reality interrupts the flow.

These things are not edge cases. They are Tuesday.

That is why we built patterns around retries, durable state, idempotent operations, compensation logic, asynchronous communication and replayable event history. Not because they sound elegant in architecture slides, but because without them production systems eventually become archaeology projects.

The Agent Layer Does Not Change the Physics

The new part is not that we suddenly have multi-step flows. We had those already.

The new part is that some nodes inside those flows are now non-deterministic. A traditional service usually behaves within a reasonably predictable boundary. It may fail, but if it succeeds, the same input is expected to produce the same kind of output. With large language models, that assumption becomes weaker. The component may summarize, classify, decide, extract, generate or call another tool, but the result is probabilistic by nature.

That does not make it useless. It makes it different.

The engineering challenge is not the box called “agent” on the diagram. The engineering challenge is uncertainty inside the node. If a component can produce slightly different answers for similar inputs, then the surrounding system needs even more discipline, not less. You need clearer contracts, stronger validation, better state management, explicit fallback behavior, auditable decisions and replayable execution paths.

Instead, I see more and more architectures where the opposite happens. A platform wires agents together through fixed and hard-coded HTTP calls, hides the control flow behind a nice interface, and expects the system to behave like a robust distributed application because the boxes have modern names.

That is not a new architecture. That is a distributed monolith wearing an AI badge.

We Are Rebuilding What We Migrated Away From

The strange part is that we already moved away from this.

For years, we told teams to avoid tightly coupled software. We encouraged modularity. We split monoliths when they became too slow to change. We introduced APIs, contracts, messaging systems, event streams, workflow engines and asynchronous processing to stop every component from holding every other component hostage.

It does not have to be Kafka, even if my slightly biased view is that Kafka is often a very good answer. It can be HTTP through proper service discovery. It can be a queueing system. It can be another durable communication layer. In the most desperate museum-grade version, it could even be an XML fileshare, although please, really, do not do this unless you also enjoy fax machines and architectural regret.

The point is not the tool. The point is the architectural principle.

Components need clear boundaries. Communication should be asynchronous where useful. State should be visible and recoverable. Events or decisions should be replayable when the business asks what happened. Failures should be observable. Retries should be safe. Operations should be idempotent where repetition is possible. Auditability should not depend on someone screenshotting a prompt response before the next execution overwrites the evidence.

When those basics disappear, the platform may still look modern from the outside, but internally it behaves like software we spent 25 years trying to escape.

Language Is Not an API

One reason this happens is that the prompt layer can be seductive. It gives the impression that complexity has moved into language, and once that illusion takes hold, teams start replacing explicit contracts with instructions written in natural language. Instead of designing clear control flow, they describe intentions. Instead of defining APIs carefully, they hope the model understands the context. Instead of building robust orchestration, they chain calls together and let the agent decide what happens next.

That sounds flexible, but flexibility without contracts is not architecture. It is ambiguity with a nicer interface.

I increasingly see the idea that APIs may be replaced by LLMs. You send a prompt, the model interprets the intent, and the system somehow decides what the answer or next action should be. For some use cases, that may be useful as an interaction layer. But language itself is not an API. An API has a contract. It defines inputs, outputs, error behavior, versioning expectations and boundaries. A prompt may describe what you want, but unless the surrounding system validates, constrains and observes the result, it does not provide the same guarantees.

That can still work in a demo. Many things work in a demo because demos are carefully selected realities with good lighting. Production is different, because production wants to know what happened, why it happened, whether it can happen again, whether it should happen again, and how to recover when it happened halfway through the flow.

In production, you need to explain decisions, replay flows, isolate failures and prove that the system did not silently skip a step because a model response looked plausible enough to pass through. You need to know which tool was called, which prompt version was used, which model produced the output, which data was available at that moment and which side effect was already committed before something failed.

If you remove the prompt layer from many current agent architectures, what remains is often very familiar. There are steps, decisions, calls to tools, data transformations and side effects. In other words, there is a workflow. The difference is not the structure. The difference is uncertainty inside the nodes, and that is exactly why the surrounding architecture needs stronger contracts, not weaker ones.

That is where the real engineering challenge lives, and that is also where many implementations are still too vague.

The Wrong Kind of Control

Some teams may hard-code connections because they want control. I understand the instinct. A direct HTTP call feels simple. It is easy to draw, easy to debug in the beginning, and easy to explain in a sprint review. One component calls another component, receives a response, and moves on.

The problem is that this kind of control often creates the opposite of control at scale.

A fixed chain of synchronous calls can make resilience worse. If one node fails, everything behind it waits or collapses. If one call times out, the system may not know whether the action happened. If one result needs to be replayed, there may be no durable record. If a downstream agent behaves differently on a retry, the system may create a second interpretation of the same business event.

That is not control. That is hope with latency.

Real control in distributed systems comes from explicit state, clear contracts, durable communication, proper boundaries and observable behavior. It comes from knowing which step succeeded, which step failed, which step can be retried, and which step requires compensation. It comes from designing for the boring failure modes before the interesting AI behavior even starts.

The irony is hard to miss. We are wrapping non-deterministic components into deterministic-looking flows, while removing the engineering mechanisms that made deterministic distributed systems reliable in the first place.

Agents Need More Engineering Discipline, Not Less

This is where the discussion should become more serious.

Agent systems are not exempt from distributed systems thinking. They are distributed systems with additional uncertainty. That means the architecture around them should become more disciplined, not more casual.

A sane agent architecture should not start with the question “How many agents can we create?” It should start with the same uncomfortable questions we should have asked anyway.

What is the contract between components? What is the source of truth? What state is durable? Can we replay a decision? Can we audit the input, output, prompt version, model version and tool call? What happens when a tool succeeds but the agent call fails? What happens when the model produces an invalid response? What happens when the same request is retried? What happens when two agents disagree? What happens when the user asks why the system did something?

These questions are not anti-AI. They are pro-production.

A system that cannot answer them is not intelligent infrastructure. It is a liability with better marketing.

The Architecture Diagram Should Still Survive Reality

There is a useful test for agent platforms and agent architectures.

Ignore the word “agent” for a moment.

Look at the system as if it were a normal distributed application. Where is the state? Where are the contracts? Where are retries handled? How is idempotency guaranteed? What can be replayed? What is observable? How are failures isolated? Where does compensation logic live? Which parts are synchronous because they must be, and which parts are synchronous only because someone hard-coded them that way at 11:47 p.m. before the demo?

If the architecture only makes sense while everybody agrees to stare at the prompt layer, then the architecture does not make sense.

This is also why I am careful with platform discussions. A polished user interface can hide a lot of architectural debt. A nice agent canvas can make hard-coded dependencies look like modular design. A successful demo can hide the absence of durable state. A clever prompt can hide the fact that the system has no real contract.

But production systems do not care about canvas aesthetics. They care about failure paths.

Final Thoughts

Agent systems are still distributed systems.

That is the core point. Not every agent idea is bad. Not every agent platform is useless. Not every HTTP call is a crime against architecture. But when we use AI as an excuse to forget everything we learned about modularity, loose coupling, state, retries, idempotency, replayability, observability and auditability, we are not moving forward. We are rebuilding the problems we already escaped from and giving them better branding.

The danger is not that agents are overhyped. Hype comes and goes. The real danger is that we let the hype lower our engineering standards.

If we want agent systems to become useful beyond demos, they need to be designed like serious distributed systems. Clear contracts. Durable state. Observable execution. Safe retries. Replayable decisions. Explicit control flow. Asynchronous communication where it makes sense.

The prompt may be new. The failure modes are not.