Right now, in 2026, agents are everywhere. Not as science fiction — as shipping products. Claude can write and execute code. Devin can build features. Cursor can refactor a codebase. These are not chatbots with delusions of grandeur. They are real-time built applications that can take actions on your behalf, navigate systems, make decisions, and produce artifacts. They are, in the most literal sense, virtual assistants who are really good at problem-solving via code.
But here is what almost nobody is talking about: agents have a design problem. Not a capability problem — that is being solved daily. A design problem. And it is the same design problem that has plagued every powerful tool in history: the quality of the output is determined almost entirely by the quality of the input.
The Context Collapse Problem
If you start cold with an agent — give it a vague task with no context about your goals, your systems, your constraints, your preferences — it will do what any capable but uninformed assistant does. It will make assumptions. It will fill gaps with plausible defaults. It will produce something that technically works but misses what you actually needed. And then you spend even more time and capital rewriting, redoing, or worse — debugging why the thing it built is subtly wrong in ways you did not anticipate.
This is not the agent's fault. It is a context collapse problem. The agent is optimizing against an incomplete picture, and incomplete pictures produce incomplete solutions. Amazon recently pulled back on some of their internal agent deployments for exactly this reason — too many redundant API calls, too much compute burned on solutions that had to be thrown away, too much time spent by humans fixing what the agent got wrong because it did not have the right context to get it right.
The question is not whether agents are capable enough. It is whether we have designed the systems that give them what they need to be useful.
The Guardrails Question
There is a real tension here that the industry is only beginning to reckon with. On one hand, agents are most powerful when they have autonomy — when they can make decisions, take actions, and iterate without waiting for human approval at every step. On the other hand, autonomy without constraint is expensive in every sense: compute costs, API calls, time spent reviewing and correcting, and the opportunity cost of what could have been built if the agent had gotten it right the first time.
Amazon's response — more guardrails, tighter constraints, explicit approval gates — is one answer. It sacrifices some of the speed and autonomy that makes agents exciting in exchange for predictability and cost control. But there is another answer, and it is a design answer: what if we got better at giving agents context upfront?
Designing for Agent Consumption
This is the part that matters for designers. We have spent thirty years designing interfaces for humans — building systems that communicate through visual hierarchy, affordances, and interaction patterns that human brains can parse. Agents do not work that way. They parse structure, not pixels. They read documentation, not designs. They need explicit context, not intuitive cues.
What does this mean practically? It means your design system needs machine-readable documentation, not just human-readable documentation. It means your component library needs explicit constraints that an agent can understand — not just visual guidelines in a PDF, but structured data about what goes where and why. It means your codebase needs to be legible to something that has never seen it before, because every time an agent starts a new session, it is seeing it for the first time.
We designed interfaces for humans for thirty years. Now we need to design context for agents — and they are very different problems.
The Upsides Are Real
I do not want to be doom-and-gloom about this. The upside of agents is extraordinary. The things I can build now — the speed at which I can go from idea to working prototype — would have seemed absurd three years ago. The mundane work that used to consume my days can be delegated. The scaffolding that used to take hours appears in minutes. When agents work well, they are transformative.
But when they work well, it is usually because someone has done the design work to make them work well. Someone wrote the documentation. Someone structured the context. Someone created the system that the agent could navigate. The agent is not magic — it is leverage. And leverage requires something to push against.
Where This Is Going
The future, I think, looks like this: a bifurcation between systems designed for agent consumption and systems that are not. The systems that are designed well will get faster, cheaper, and more reliable as agents improve. The systems that are not will become increasingly expensive to operate — not because the agents are bad, but because the agents are constantly fighting against missing context, ambiguous constraints, and structures that were never built for them.
For designers, this is both a threat and an opportunity. The threat is that design work gets automated by agents that do not understand what they are doing. The opportunity is that someone needs to design the systems that make agents actually useful — the context layers, the constraint frameworks, the documentation that turns a capable but blind assistant into a capable and informed one. That is design work. It just looks different than what we have been doing.
The designers who understand this will thrive. The ones who do not will spend a lot of time cleaning up after agents that never had what they needed to get it right the first time.