The death of the UI? MCP, AI agents and the software we’ll actually build next
Quick Answer: The Model Context Protocol (MCP) is an open standard that lets AI agents use your software directly, through a structured interface instead of your screens. That has people asking whether the user interface is dying. It isn’t. Software is gaining a second kind of user: alongside the human who still needs a clear, accessible interface, there’s now an agent that needs clean data, a sane API and MCP access. The teams that win design for both.
There’s a tidy story doing the rounds. AI agents are getting good at using software. A new standard, the Model Context Protocol, lets them plug straight into your systems. So why build screens at all? Give the agents a structured interface, let people talk to the agent, and the user interface quietly dies.
It’s a good provocation. It’s also wrong, in a way that matters for anyone deciding what to build next. The UI is not dying. It is splitting in two. And the split is, at its heart, a design problem before it is an engineering one.
What the Model Context Protocol actually changes
The Model Context Protocol is an open standard, introduced by Anthropic in late 2024 and since adopted widely, for connecting AI assistants to the systems where data and tools live. You can read the specification and the reasoning behind it directly. The short version: instead of every AI integration being a bespoke one-off, MCP gives software a standard way to expose its data and actions so that an agent can discover and use them. An MCP server is the piece you build (or adopt) to expose a given system that way.
What changes is the assumption that has held since the personal computer: that software is something a person operates through an interface. For thirty years the screen was the only door in. MCP adds a second door, one built for a non-human operator. An agent can now read your data, call your functions and complete a task without ever touching the screen a person would use.
That is genuinely significant. It is also not the end of the interface, for the same reason the API did not end the interface twenty years ago. A new way for machines to talk to software does not remove the human’s reasons for needing one. It adds a second audience.
Your software now has two users
Here is the reframe the “death of the UI” story misses. Software used to have one user: a person, looking at a screen. Now it has two.
- The human still needs an interface. They need to see what’s happening, trust it, correct it, handle the cases the agent can’t, and stay accountable for the outcome. None of that goes away because an agent can also act. If anything, the human’s interface gets more important, because their job shifts from doing the work to supervising and deciding.
- The agent needs something different: a clean API, a well-modelled and predictable data layer, clear descriptions of what each action does, sane permissions, and an MCP server that exposes all of it safely. An agent driving a messy, undocumented system fails in exactly the places a confused new employee would.
Most software today is built well for the first user and barely at all for the second. The data model is shaped around the screens, the logic is tangled into the interface, and there is no clean seam an agent could use even if you wanted to expose one. The work of the next few years is not deleting the human interface. It is finally building the second one properly, and connecting the two so a person can watch and steer what the agents are doing.
Why “just let people talk to the agent” misreads the problem
The appealing version of the death-of-the-UI story is that it means less work. One chat box, agents doing the work underneath, no screens left to design.
It means the opposite. Letting an agent drive your software does not remove the hard work, it renames it. For an agent to act safely, the software underneath has to be genuinely well built: the data well modelled, every action clearly defined and limited, permissions real, behaviour predictable. Those are the hardest parts of building software, and the first things a rushed build skips. Hand an agent the controls of a system that was only ever meant for a careful human, and it does not work carefully faster. It makes mistakes faster, and more of them than any person could.
The person does not disappear either. Someone still has to decide what the agent is allowed to do, see what it did, catch it when it goes wrong, and answer for the result. That is an interface too, a new kind built around oversight, judgement and trust rather than data entry, and almost nobody has designed it well yet.
Designing for agents is still design
This is where the “death of the UI” framing gets the conclusion exactly backwards. If software now has two users, you have not removed design from the picture. You have doubled it.
Designing for the human user is the work we have always done: research, information architecture, interface, accessibility, the experience of using the thing. Designing for the agent is the same discipline pointed at a new user with different needs: what actions should it be able to take, how should they be described so it uses them correctly, what should it never be allowed to do, how does a person stay in the loop, and how is all of that exposed through an MCP server cleanly and safely. Some people are starting to call this agent experience, or AX. The name matters less than the recognition that it is a design problem, not just a plumbing one.
This is the pattern we have watched play out before. The real work in building software has been moving up the stack for years, from screens, to systems, to data models, and now to the experience of the agents that will use them. The stage that decides whether software is agent-ready has a name: architecture. The data model, the system structure and the API an agent depends on are all settled in the systems design and architecture phase, before there is an interface to look at, and that is exactly where you design those foundations to be correct for an MCP application. The proportion of value that sits in thoughtful design and sound architecture rather than raw construction keeps rising, which is the shift we have built our practice around. Agents are the newest reason that engineering has to be design-led, not the reason design goes away.
For us that is not a pivot. The systems we build already have to be well modelled, well documented and cleanly separated from their interfaces, because that is what makes them maintainable, integrable and accessible. A system built that way is, almost incidentally, a system an agent can use safely. The teams that have been cutting corners on the data model and bolting logic onto the screens are the ones with the most work to do, because there is no clean seam for the second user to plug into.
How to build software for two users
If you are commissioning or planning software now, you do not need to bet the build on agents to be ready for them. You need to build well, with the second user in mind. This is the working checklist.
- Model the data properly. A clean, well-structured data layer is the foundation both users stand on. An agent magnifies the cost of a messy one.
- Separate logic from the interface. Business logic that lives in a real application layer can serve a screen, an API and an agent alike. Logic tangled into the UI can serve only the screen.
- Expose actions through a clean, well-described API. This is what an MCP server is built on. Clear names and clear boundaries are what let an agent use it correctly.
- Make permissions real and granular. Decide what an agent is allowed to do, separately from what a human is, and enforce it in the system, not the interface.
- Design the human’s supervisory interface deliberately. As agents do more of the doing, the person’s job becomes oversight, exceptions and decisions. Design for that, not just for data entry.
- Keep accessibility and trust central. The human interface does not get less important because agents exist. For most systems it gets more important, because a person is now accountable for what the agents did.
The first four of those are, together, your application’s architecture, and they are where agent-readiness is won or lost. Get the data model and the API right and an MCP server sits on top as a thin layer; get them wrong and no amount of interface work will rescue it. Build to the full list and you are ready for agents whether they arrive next quarter or next year, and you have better software for the humans in the meantime.
Where this leaves the interface
Conduct has spent over 15 years, since 2008, building custom software and the interfaces people use to run it, for government, health, enterprise and not-for-profit organisations. We are an in-house Australian team of senior engineers and designers, a 7-time Good Design Award winner, and our engineering has always been design-led, which is exactly the posture this shift rewards. If you are thinking about what AI agents mean for the systems you are planning, talk to us about custom software development. The honest answer is usually that the fundamentals you needed anyway, a clean data model and a thoughtful interface, are also what makes your software ready for agents.
The user interface is not dying. It is dividing into two: one for the people who need to see, trust and decide, and one for the agents who need to act. Design just got a second user. It did not get less important. It got bigger.
Frequently asked questions
What is the Model Context Protocol (MCP)?
The Model Context Protocol is an open standard, introduced by Anthropic in late 2024, for connecting AI assistants and agents to the systems where data and tools live. Instead of every AI integration being a bespoke one-off, MCP gives software a standard way to expose its data and actions so an agent can discover and use them safely. It has been adopted widely across the industry as the common way to make systems agent-accessible.
Will AI agents replace user interfaces?
No, but they change what interfaces are for. Agents add a second way to use software, a structured one built for machines, alongside the screens built for people. The human interface does not disappear; it shifts towards oversight, exceptions and decisions as agents take on more of the routine doing. Software ends up with two users, the human and the agent, and well-built systems serve both rather than dropping one.
What is an MCP server?
An MCP server is the component that exposes a given system, your application, database or tool, to AI agents through the Model Context Protocol. It describes what data is available and what actions can be taken, with permissions and boundaries, so an agent can use the system correctly and safely. Building one well depends on the underlying software having a clean API, a sound data model and real permissions to expose in the first place.
What is agentic AI?
Agentic AI refers to AI systems that don’t just answer questions but take actions to complete tasks: planning steps, calling tools, using software and working towards a goal with limited supervision. Where a chatbot responds, an agent does. The Model Context Protocol is one of the standards that makes this practical, by giving agents a consistent way to reach the systems they need to act on.
How do I make my software ready for AI agents?
Build the fundamentals well: a clean, well-structured data model, business logic separated from the interface and held in a real application layer, a clearly described API, and granular permissions enforced in the system. Those let you expose the software safely through an MCP server. They are also what make software maintainable and integrable regardless of agents, so being agent-ready is mostly a by-product of being built well.
Should I build my software for AI agents now, or wait?
You do not need to bet a build on agents to be ready for them. Build the fundamentals well, a clean data model, a clear API, real permissions and logic kept separate from the interface, and you have software that is easier to run today and ready for agents whenever they become relevant to your work. Being agent-ready is mostly a by-product of being built well, so there is little reason to wait, and little reason to over-invest in a bet that has not yet landed.
Charlie Pohl
