We’re Building Agentic AI Like It’s Still the Mainframe Era
I think we’ve seen this architectural shift before.
A lot of enterprise AI is being built around centralised use cases. Someone defines a process, builds an agent or a chain of agents to carry it out, and gives the user an interface to submit a request.
The intelligence sits in the middle. The user gets access to whatever someone has decided to build.
It’s remarkably similar to the mainframe model. You have a terminal through which you interact with centrally defined capabilities. If you want to do something those capabilities don’t support, you need someone to build it.
Now we’re doing it again with agents.
I think the more useful analogy for where this goes next is the client–server revolution. The client is your personal agent (Claude Co Work, Codex Work, Meta Muse, Microsoft Co Work the list is becoming endless). The servers provide access to the enterprise’s tools, information, actions and controlled processes.
That changes what we should be building.
The personal agent is the client
Think about what happened when the client became capable of doing useful work itself.
People could combine applications, manipulate information and work through problems without every activity having to be implemented as a central application. Shared systems still mattered, but much more could happen around the person doing the work.
A personal agent takes that idea further.
It understands what you’re trying to achieve, works out which capabilities it needs and brings them together on your behalf. You can ask it to prepare for a meeting, investigate a discrepancy, update a customer record or work through something nobody has thought to put on an AI roadmap.
The use case becomes something you carry out through your agent. It doesn’t always need to be something the organisation builds separately.
That’s quite a fundamental change in where the effort goes.
Your enterprise systems become the servers
Underneath the personal agent are the systems your business already relies on.
Systems of record hold information about customers, contracts, transactions and the state of the business. Systems of execution let you act: raise an invoice, change an order, deploy software or submit something for approval. A single application might do both.
You expose those capabilities through MCP servers, APIs, command-line interfaces and other tools the personal agent can use. MCP, the Model Context Protocol, provides one way to make those capabilities available to agents.
Some systems may have specialist agents in front of them. A specialist agent can know a great deal about operating a particular application, while your personal agent understands why you need to use it.
The architecture has a useful division of responsibility. Your personal agent understands you and the task. The services underneath it provide dependable access to the business, within your identity and permissions.
The same capabilities can serve many people and many different requests.
You stop having to build every combination
Say I’m preparing for a customer meeting.
My personal agent retrieves the account history, checks outstanding delivery work and looks at the commercial position. After the meeting, I ask it to update the opportunity and prepare a proposal.
Then I notice something odd.
Get David Fearne’s stories in your inbox
Join Medium for free to get updates from this writer.
“Can you check whether this proposal is consistent with what we agreed last month, and whether any of that work has already been invoiced?”
That crosses several systems and probably a few organisational boundaries. It’s also a perfectly ordinary question for a person to ask.
In a use-case-led architecture, we can end up treating each variation as another thing to design and deliver. With a capable personal agent, we can combine the services we already have around the question in front of us.
There will still be missing capabilities to build. But each new capability can support a multitude of use cases, including exceptions and ad hoc work we didn’t anticipate.
That’s why the client–server analogy matters. It gives the organisation a way to provide shared capabilities while giving the individual much more freedom in how to use them.
The client also gets to know you
There’s another important difference: your personal agent should improve through working with you.
It learns what you’re responsible for, how you make decisions and what you mean when you ask for something. You explain an exception, correct an assumption or show it what a good result looks like.
Those interactions should leave something useful behind.
The agent needs to crystallise the relevant information into persistent memory on your behalf: a preference, a decision, a piece of context or an explanation it can retrieve next time.
Over time, you should spend less effort explaining yourself. It should ask better questions and avoid repeating mistakes you’ve already corrected.
The ambition is simple: the first time you use your personal agent should be the slowest and dumbest it ever is.
That accumulated understanding can help across your work. Something learned while preparing a proposal might be relevant when reviewing an invoice or planning the next customer meeting.
The personal agent provides continuity across all those activities.
The rigid processes sit behind that architecture too
Some procedures need to run in a very particular way.
Complete these checks. Obtain this approval. Record the evidence. Stop if a condition isn’t met.
For highly controlled work, we may deliberately want almost no autonomy. In architectural terms, that component is getting much closer to a tool. It performs a defined operation within enforced boundaries.
Your personal agent can invoke it, provide the inputs and help you interpret the result. The procedure itself retains its mandatory checks and audit trail.
That fits comfortably into the client–server model. A capable client can use a tightly controlled service. The client’s flexibility doesn’t require the service to become flexible as well.
It also means the organisation can maintain one dependable implementation of that procedure and make it available wherever it is needed.
Dedicated agents still have a job
There’s still a place for custom agents with specific responsibilities.
“Do this thing every day” may justify a scheduled agent. Monitoring a service may justify an agent that runs continuously. A specialist system agent may need substantial knowledge of the application it operates.
Those are capabilities your personal agent can work with. They can run independently, receive delegated work and return results.
The central architectural question is where we put the general ability to help a person do their job. My view is that it belongs with the person, supported by shared enterprise services. As it is today.
So when we plan enterprise AI, we should be asking how to make our systems of record, systems of execution and controlled procedures usable by personal agents at scale.
Get that foundation right, and people can carry out a huge range of work through an AI colleague, that increasingly understands them, the systems they use and the “use cases” that define their role.
