Is Agentic AI just Old Software Engineering with New Names?
Orchestrators, planners, tool use, agent memory, guardrails. Experienced engineers look at the agentic AI vocabulary and ask a fair question. Haven't we built all of this before? The honest answer is yes and no. This post is about the no.
Most agentic AI terminology maps cleanly onto things distributed-systems engineers already know. Orchestration is workflow management, multi-agent systems are message passing, tool use is an API call behind a dispatcher. But the component at the centre is a probabilistic machine programmed in English. That one difference changes testing, monitoring, security, and cost more than the familiar parts suggest.
The suspicion is fair
Every few years the software industry invents new vocabulary and declares a revolution. Right now that vocabulary belongs to agentic AI and multi-agent systems. Orchestrators, planners, tool use, agent memory, guardrails. The terms are everywhere, and so is a quiet suspicion among experienced engineers. Haven't we built all of this before?
The honest answer is yes and no. The architecture is mostly familiar. The component at the centre of it isn't. That one difference changes how you test, monitor, secure, and pay for these systems.
The parts you already know
If you've spent a decade or two building distributed systems, most agentic terminology maps onto things you already know.
| New name | What it is | Where you've seen it before |
|---|---|---|
| Orchestration | Workflow management | BPM engines, Airflow, Temporal, state machines. An orchestrator routing tasks between steps is a DAG executor. |
| Multi-agent systems | Message-passing architecture | The actor model (Erlang, Akka). Microservices with pub/sub. Independent components talking over queues and topics. |
| Tool use | An API call behind a dispatcher | The command pattern with a router. The model emits a structured request, a runtime executes it. |
| Agent memory | State management | Caches, vector databases, session storage. Short-term memory is a context buffer. Long-term memory is a database with a retrieval layer. |
| Guardrails | Input validation and policy enforcement | Defensive programming at trust boundaries. Same as always. |
| Planner / executor | A control loop | Classic control loops, the mediator pattern, hierarchical task planning from the GOFAI days. |
Even the academic idea isn't new. Multi-agent systems research dates back to the 1980s and 90s, complete with BDI agents, blackboard architectures, and FIPA communication protocols. A lot of today's excitement is a rediscovery of that literature, usually without the citations.
So the sceptics have a point. If someone tells you multi-agent architectures require throwing out everything you know about software engineering, they're selling something. Queueing, idempotency, retries, backpressure, failure isolation. That knowledge is still the single best preparation for building these systems.
If the vocabulary itself is the problem, the Agentic AI glossary on this blog defines every one of these terms with a diagram. The Agentic AI track in this app shows each mechanism moving step by step.
A probabilistic component programmed in English
The it's all the same argument breaks down at the component itself. Traditional software engineering rests on one assumption. Components are deterministic. Same input, same output. Contracts are enforced by types and schemas. Failures are loud.
Put an LLM in the middle of your system and every one of those assumptions bends or breaks. Five things actually change.
1. The spec is a prompt, and the behaviour is a distribution
You can't formally verify a prompt. The specification of an agent is natural language, and its behaviour is a probability distribution over outputs. So testing changes. You stop asserting that one input gives one output, and you start measuring pass rates across suites of eval cases. Eval-driven development is a genuinely new discipline. The closest thing we had before is testing ML models, not testing code.
2. Failures are plausible, not loud
A broken API call throws a 500. A broken agent returns something that looks right and isn't. The failures are semantic. A summary that's wrong but sounds sure of itself. A plan with one step quietly missing. A hallucinated field that still passes your schema check. Monitoring has to move from did it error? to was it correct?. Answering that often takes another model, a human, or downstream signals.
This blog already covers that problem end to end in Debug an AI Agent that's only sometimes Wrong, from traces and online evaluations to how a real incident actually gets solved.
3. The model decides the control flow at runtime
In classic orchestration, a human writes the DAG. In agentic systems, the model chooses which tools to call, in what order, and when to stop. Nobody wrote the control flow. It only exists at runtime, which changes how you reason about correctness, cost, latency, and security.
Prompt injection is not renamed SQL injection. SQL injection exploits a parser, and you can fully sanitise against it. Prompt injection is different. Instructions and data travel through the same natural-language channel, and there's no formal boundary between them. There's no equivalent of parameterised queries for prompts yet. That's a new attack surface.
4. Errors compound
Chain five deterministic services with 99.9% reliability and you're fine. Chain five stochastic agents that are each right 90% of the time and your end-to-end success rate is about 59%. The microservices era taught a version of this lesson (you are not Netflix). With agents the same lesson arrives much faster, because the errors multiply.
Experienced builders keep landing on the same advice. A single capable agent with good tools usually beats an elaborate multi-agent architecture.
5. Tokens, latency, and drift
Cost used to scale with compute and storage. Now it scales with tokens per call, and a runaway agent loop can burn real money in minutes. Model versions also drift underneath you, and the same prompt behaves differently after a provider update. So prompt versioning, pinned models, and continuous eval baselines become part of your CI, the way dependency pinning once did.
What transfers, and what's new
The distributed-systems toolkit transfers almost untouched. Message-passing patterns, failure isolation, retries and timeouts, least-privilege access, logging and tracing, and the instinct to keep architectures as simple as possible all apply from day one.
The new work sits around the model. You test with evals instead of assertions, and judge output quality with another model in the loop. You version prompts the way you version code, defend an instruction channel you can't fully sanitise, and budget in tokens. All of it designs around a component whose correctness is a probability, not a guarantee.
So, is it just old software engineering?
The architecture is old software engineering with new names. The component running inside it is new, probabilistic, programmed in natural language, and able to be wrong in ways that look right. And that changes how you have to build the architecture around it.
Treat agentic AI as a brand-new field and you waste thirty years of distributed-systems experience. Dismiss it as pure rebranding and you miss the part that actually changed. Do both instead. Bring the old discipline with you, and take the non-determinism at the centre of it seriously.