Two ways to structure a system
There are two fundamental ways to organise the logic inside any software system. The first is a simple, stateless unit — something that takes an input, performs one job, and hands back a result. The second is a self-contained component that holds its own state and exposes a set of related capabilities that all operate on that state together.
Most infrastructure architects already think in the second pattern without naming it that way. A storage array is not a collection of unrelated commands — it is a single entity with configuration, state, and a defined set of operations that all act on that same state consistently. A network switch behaves the same way. So does a virtual machine. The architecture holds state and behaviour together, deliberately, because that is what makes the system predictable and safe to operate at scale.
This is exactly the architectural decision that separates simple automation scripts from proper AI frameworks.
Why AI systems are built as self-contained components
Every serious AI system — whatever tools or platform it is built on — is architected around self-contained components that hold their own state. An agent holds its memory, its configuration, its tool connections. A retriever holds its index, its embedding strategy, its connection to a data source. Each component exposes a defined set of operations that act on that internal state consistently.
This is not a stylistic choice by the framework authors. It is the same architectural necessity that governs any system that needs to manage state reliably across many isolated instances at once — multiple agents, multiple conversations, multiple retrieval sessions, all running independently without interfering with each other.
An engineer who understands only how to call a function can follow a tutorial. An engineer who understands why a system is architected around self-contained, stateful components can read the framework's internals, understand what each component is actually responsible for, and make an informed decision about where to extend it safely. That distinction is the entire difference between operating a system and being dependent on whoever built it.
Shared structure, specialised behaviour
A second architectural pattern worth recognising is how these frameworks avoid repeating themselves. A common structure is defined once — the base shape of "an agent" or "a retriever" — and specific variations inherit that shared structure while only changing what genuinely differs.
Infrastructure teams do this constantly at the platform level. A base server image, hardened and standardised once, becomes the foundation for every workload-specific variant deployed on top of it — each one inheriting the shared baseline and only diverging where the actual requirement differs. AI systems apply the identical principle to their internal architecture. A base reasoning loop — observe, plan, act, reflect — is defined once. A research agent and a coding agent both inherit that same loop, differing only in how they plan.
Recognising this pattern when evaluating an AI platform tells you immediately where the real customisation points are, and where you are looking at shared, load-bearing infrastructure that should not be touched carelessly.
Interchangeable components behind a consistent interface
The third pattern is what allows these systems to swap components without breaking the systems built on top of them. Different retrieval sources — a vector database, a document store, a search index — can all be swapped behind the same consistent interface, because each implements the shared operation according to its own internal logic while presenting an identical contract to everything that calls it.
This is precisely the design principle behind infrastructure abstraction layers — a storage interface that behaves consistently whether the backend is flash, hybrid, or object storage; a load balancer configuration that works the same way regardless of which backend pool it is routing to. The value is the same in both domains: the system built on top does not need to change when the underlying component does.
Why this matters more than the platform choice
Teams evaluating AI vendors and platforms often focus the conversation on which one to select. The more consequential question is whether the team evaluating them understands the architectural principle all of these systems share. A platform choice can be changed later. Architectural literacy either exists on the team or it does not.
Infrastructure teams that have spent years designing systems around shared state, inheritance of standard configuration, and interchangeable components behind stable interfaces are not starting from zero when they approach agentic AI. They are recognising a familiar architecture wearing a new name — and that recognition is what allows them to evaluate, extend, and operate these systems with the same discipline they already apply everywhere else in the environment.