I have been thinking about agentic architecture as layers.
I was doing some work on Orchistra, which is the communication platform I am building for agentic workers. The simplest way to describe it is Slack-like, but built for agents first. Humans can see what is going on, but the work room is designed so agents can communicate, hand off, leave receipts, and be overseen properly.
While I was working through it, I realised I was not just building one thing.
I was building an onion.
That is now how I think about agentic systems. Not as one clever model, one harness, one app, or one workflow. Layers. Each layer has a job. Each layer can fail. Each layer changes what the layer above it can safely do.
The ground layer
At the bottom is the ground.
Where is this thing running? Is it on a laptop, a Mac Mini, a VPS, a cloud region, a sovereign environment, a client tenancy, or someone else's managed platform?
That sounds basic, but it is not. The physical and hosting layer decides a lot:
- which jurisdiction applies
- how fast the system is
- how resilient it is
- who can turn it off
- where logs and data might live
- what recovery looks like when it goes wrong
Before I get excited about agents, I need to know where the ground is.
The access layer
The next layer is access.
How do I securely get to the server? How do deploys happen? Is there a forced route, a managed gate, a CI process, a signed release, a human approval, or someone with a shell and too much confidence?
Agentic systems make this more important, not less. If agents can make changes, then access is no longer just about who can log in. It is about what can act, what route it must use, and what proof is left behind.
This is where deployment lanes matter. A good agentic architecture should not rely on broad access. It should have narrow, named paths for action.
The runtime layer
Then come the runtimes.
What is in containers? What is in services? What is scheduled? What is long-running? What restarts cleanly? What happens when the laptop sleeps, the VPS reboots, the connection drops, or a dependency is unavailable?
This is the part that looks boring until it breaks.
If you cannot describe what is running, where it runs, and how it comes back, then you do not have an agentic platform. You have an interesting demo with a memory problem.
The data layer
After runtime comes data.
Where is the data stored? Is it a filesystem, a database, a document store, a vector index, a cache, a queue, a CRM, a SharePoint library, a local file, or an external SaaS platform?
Then the harder questions start.
Who owns the data? What is the source of truth? How fresh is it? How fast does it need to be accessed? Is the data public, internal, confidential, client-private, personal, or operationally sensitive?
A lot of agentic mistakes are not model mistakes. They are data-layer mistakes. The agent was allowed to look at the wrong thing, combine two things that should not meet, or act on stale information as if it were current.
The protocol layer
Then there is communication.
How does the agent reach the data or the tool? Is it using an API, an MCP server, a queue, a websocket, a file drop, an event log, an agent-to-agent protocol, or a local command?
This is where architecture becomes less about "can it connect?" and more about "can it connect safely, repeatedly, and observably?"
A protocol is not just a pipe. It is a contract. It tells the system what shape a request should have, what shape a response should have, what errors mean, and what can be audited afterwards.
The identity layer
Above that sits identity and authentication.
What is the agent allowed to be? Is it acting as itself, as the user, as a service account, as a lane, as a company role, or as a temporary delegate?
This matters because agentic work blurs a line that older systems used to keep fairly simple. A human clicked a button. A service performed an action. An audit log showed both.
With agents, the action may have been proposed by one agent, checked by another, approved by a human, executed by a tool broker, and recorded by an overseer. That means identity needs to be explicit.
The firewall layer
Then we get to the firewall layer.
I do not mean only a network firewall. I mean the shape-checking layer around agentic action.
What does a valid request look like? What content is allowed? What is suspicious? What is impossible? What should be paused? What must be refused?
This is where LLM firewalls, schemas, tool gates, approval rules, stop-lines, permissions, and content boundaries live.
The model can think. The system still has to decide whether the action is allowed.
The application layer
Now we can talk about applications.
Is the interface HTML? Is it Swift? Is it a Windows app? Is it iOS, Android, terminal, desktop, or a background service?
This is where a lot of people start, because this is the thing they can see. But by the time you get here, the important decisions have already been made underneath.
An application is only as safe as the layers below it.
The work layer
Then comes the work itself.
What is the agent trying to do? Is it researching, writing, testing, deploying, triaging, selling, reconciling, monitoring, teaching, or reviewing?
What lane is it in? Who owns the work? What does good look like? What is the next action? What counts as done? When does it need to ask?
This is where systems like Orchistra become useful. The point is not just to give agents somewhere to chat. The point is to give them an operating room with channels, lanes, receipts, handoffs, escalation, and a visible record of what happened.
That is the difference between agents doing tasks and agentic workers operating in an environment.
The operator view
There is one layer I would call out specially: visualisation.
Once you have several agents, you can still hold the system in your head. Once you have tens of agents, maybe. Once you have hundreds of agents across multiple machines, systems, clients, and environments, you cannot.
At that point, you need an operator view.
You need to see what is running, what is blocked, what is waiting for you, what has spent money, what has touched data, what has failed, what has escalated, and what is quietly drifting.
If you cannot see the work, you cannot govern the work.
The cross-cutting layer
All of this is wrapped in the disciplines that cut through every layer.
Code management. Security. Secrets. Data governance. Operational resilience. Exploit checks. Backups. Recovery. Logs. Cost control. Privacy. Change management. Documentation.
These are not separate admin jobs you add at the end. They run through the whole onion.
A weak security model at the access layer becomes a dangerous tool call at the agent layer. Poor data labelling becomes an accidental disclosure at the response layer. Bad deployment discipline becomes a production incident that the agent cannot understand.
Compilers were the lesson
I think one of the useful historical comparisons is the compiler.
Compilers changed software development by letting us work at a higher level. We did not have to write everything in machine code. We did not have to manage every low-level operation directly. The abstraction made us dramatically more productive.
But the lower layers did not disappear.
Memory still existed. Filesystems still existed. Networks still existed. The machine still mattered. The difference was that most of the time we could work at a better level.
Agentic systems are doing something similar.
The point is not that we can forget servers, containers, data, authentication, protocols, firewalls, and operational resilience. The point is that, when those layers are in place, we can work higher up.
The practical test
When an agentic system feels confusing, I now ask a simple question:
Which layer is failing?
Is the server wrong? Is access too broad? Is the container messy? Is the data stale? Is the protocol unclear? Is identity confused? Is the firewall missing? Is the application awkward? Is the work undefined? Is the operator blind?
That question makes the problem smaller.
It also stops us pretending that agentic architecture is just prompt engineering. It is not. Prompting matters, but it sits inside an environment. The environment is the architecture.
Build the onion. Know which layer you are working at. Then let the agents help, but make sure the layers underneath can hold.