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.
The part that interests me gets discussed less: agents have a design problem. Capability is being solved daily. This is the same problem that has followed most powerful tools: 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: make assumptions, fill gaps with plausible defaults, and produce something that technically works but misses what you actually needed. Then you spend more time and money rewriting, redoing, or debugging why the thing it built is subtly wrong in ways you did not anticipate.
This is a context collapse problem more than an agent failure. 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 real question is less whether agents are capable enough than whether we have designed the systems that give them what they need to be useful.
The Guardrails Question
There is a real tension here. 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 work differently. They parse structure rather than pixels, and they need explicit context rather than intuitive cues.
In practice, your design system needs machine-readable documentation alongside the human-readable kind. Your component library needs explicit constraints an agent can understand: structured data about what goes where and why, not just visual guidelines in a PDF. And your codebase needs to be legible to something that has never seen it, 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 am not pessimistic about agents. The things I can build now, and how fast I get from idea to working prototype, would have seemed absurd three years ago. The mundane work that used to consume my days can be delegated, and scaffolding that took 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, structured the context, and built a system the agent could navigate. The agent is not magic, it is leverage, and leverage needs something to push against.
Where This Is Going
I think the future splits into systems designed for agent consumption and systems that are not. The first kind will get faster, cheaper, and more reliable as agents improve. The second will get more expensive to operate, not because the agents are bad, but because they keep fighting missing context, ambiguous constraints, and structures that were never built for them.
For designers, this cuts both ways. The risk is that design work gets automated by agents that do not understand what they are doing. The opening is that someone has to design the systems that make agents useful: the context layers, constraint frameworks, and documentation that turn a capable but blind assistant into an informed one. That is design work. It just looks different from what we have been doing.
Designers who understand this will spend less time cleaning up after agents and more time shaping the systems those agents rely on.