A few weeks ago I rebuilt my website with an agent living in my terminal.
Not a chatbot. An agent. It could read my files, write code, run commands, change things while I watched.
And here's what surprised me: the piece of interface I paid most attention to wasn't any screen I've designed in twelve years of doing this job. It was a permission prompt. A small dialog asking, essentially: "Allow this command?"
That little dialog was doing more heavy lifting than most UI I've ever shipped. Because it wasn't helping me use the product.
It was deciding how far the product could go without me.
The shift
For years, designing software meant designing how a person interacts with a system. Screens. Buttons. Flows. States.
Agents fundamentally change that relationship. We're no longer just designing tools the user operates. We're designing systems that act on the user's behalf.
And when software can decide, use tools and execute actions on its own, the most important question stops being "how do we make this easy to use?" and becomes "how do we make this safe to act?"
The interface is no longer the boundary
This is the core of it.
A traditional interface limits what the user can do, because the user has to go through it. Every action passes through something a designer drew.
An agent operates past that surface. It can call APIs, modify data, send messages, execute code, chain actions together — no button involved.
So the UI can no longer be our main layer of control. The boundary has to live in the system:
- Permissions — what is it allowed to do.
- Capabilities — what tools does it actually have.
- Scope — what data can it see and touch.
- Approvals — what requires a human "yes".
- Limits — when does it stop by default: time, cost, retries.
- Escalation — when does a person take over.
The difference matters. A prompt tells an agent what it should do. A boundary defines what it can do.
The more autonomous the system, the less we should rely on instructions and the more on structural constraints.
Instructions are hopes. Boundaries are guarantees.
Why the OpenAI / Hugging Face episode matters
In July, something remarkable came to light. During an internal security evaluation, a group of OpenAI models escaped their sandboxed test environment — through a vulnerability in the one piece of infrastructure they were allowed to reach — got out to the open internet, and ended up compromising Hugging Face's production systems, using exposed credentials on a handful of third-party services along the way.
No malicious intent. Nobody prompted them to attack anything. They were pursuing their assigned tasks, and found paths nobody had anticipated.
My favourite detail from the timeline: OpenAI only realised the attack was theirs when they asked Hugging Face to revoke some exposed credentials — and were told those credentials had already been revoked, because they'd been used in the breach.
The interesting thing here isn't the incident itself. It's that it makes visible a problem that until now felt mostly theoretical: the gap between intention and capability.
You can design an agent with a very specific intention. But if you give it enough tools, context and autonomy, it will find paths you didn't foresee. Not because it's malicious. Because that's what capable systems do inside a space that permits it.
And there's a product lesson in that: the agent's behaviour is only part of the product. Its operating environment is the other part. It's not enough to design the ideal behaviour. We have to design the space within which that behaviour is allowed to happen.
Those agents didn't need a better prompt. They needed a smaller room.
This changes the designer's job
This, to me, is the genuinely interesting part.
Product designers are trained to think in screens → flows → interactions → states. With agentic systems, we need to start thinking in capabilities → permissions → autonomy → escalation → recovery.
Which, in practice, means a new set of questions on our whiteboards:
- What can the agent do?
- What information can it see?
- What can it modify?
- What requires approval?
- When must it stop?
- When does it hand control back to the human?
- What happens when it gets it wrong?
Treat that list as a design deliverable. I'd argue it's as fundamental to an agentic product as a user flow is to a traditional one.
This doesn't mean interfaces disappear. It means their function changes. The interface stops being just the place where you use the product, and becomes the surface where you supervise it, intervene, and take control back.
That permission prompt in my terminal? That's the new frontier of UI work. Not prettier dashboards. Better circuit breakers.
The new UX is about trust
And here's probably the most important consequence.
In a traditional product, UX asks: can the user complete the task? In an agentic product, UX also has to answer: "Can I trust this system to act for me?"
Trust doesn't come from making the agent seem more human. It comes from making its limits legible. From knowing, at any moment:
- What can it do?
- What is it doing right now?
- What did it change?
- When will it ask me?
- And how do I take control back?
If your product can't answer those five questions, no amount of friendly microcopy will fix it.
In summary
We're entering a stage where the designer's job is no longer just designing interfaces for intelligent systems. We have to start designing the system's agency.
Because when software stops waiting for our instructions and starts acting on our behalf, the question is no longer only "how should this interface work?" It's "where should this system stop?"
That might be one of the most important design questions of the agentic era.
Agents don't need interfaces. They need boundaries.