Introducing Agent-Centered Design
For about thirty years, we designed software around a human on the other side of the screen. That assumption is breaking. A growing share of the traffic hitting your APIs, reading your docs, and calling your tools now comes from an AI agent.
When the operator is a machine, "good design" means something different. Agent-centered design is the practice of building for that reality on purpose.
The definition we will use throughout:
Agent-centered design is a technique that puts AI agents at the center of the development process, delivering products built by and built for agents as the primary end user.
The definition has two halves. Software is increasingly built by agents, and increasingly built for agents. Both run through this piece.
What the term means
The two halves of designing software for AI agents reinforce each other.
Built by agents
AI agents are becoming first-class participants in the development process itself. They write, test, deploy, and operate software, rather than sitting beside a human as a smarter autocomplete. The human role moves up a level: you define what to build and what "done" looks like, then review the outcome.
Built for agents
The product's primary consumer is assumed to be an agent. So the APIs, documentation, outputs, and tools are designed for a machine to discover and operate on its own, with human developers still orchestrating the work.
The pivot behind both halves is a change in who the end user is. For roughly three decades, software design meant human-centered design, the discipline behind good user experience. Agent-centered design keeps the discipline and swaps the user.
Built by agents: the development loop
When an agent can carry out large parts of the build, test, deploy, and operate loop, the developer's job changes shape. You spend less time writing every line and more time setting boundaries: deciding what to build, defining the interfaces and tests that bound each unit of work, and specifying what "done and safe" means.
The industry has started to name the layer that makes this reliable. Call it the harness: the scaffolding of tools, permissions, constrained action spaces, and tests that keeps a non-deterministic model behaving predictably. A model on its own is capable but unpredictable. A well-built harness turns that capability into work you can trust, because the agent can only act inside boundaries you set and every action is checked against tests you wrote. Anthropic's engineering guidance on writing effective tools for AI agents is one of the clearest public articulations of how to shape that action space.
Let’s be honest about where this stands. Fully autonomous agents are still early, and reviewing what an agent produces is real work. Developer surveys in 2025 show enthusiasm for AI assistance alongside genuine caution about trusting its output, and the cost of reviewing generated code is a recurring theme (Stack Overflow 2025 Developer Survey). Agent-centered design assumes agents do a growing, still-partial share of the work, and that deliberate guardrails are how you capture value from that shift without losing control.
Built for agents: the agent as the consumer
Now flip to the other half. Assume the caller is a machine, and your design targets move.
An agent does not appreciate visual polish or forgive ambiguity. It needs contracts it can rely on: stable structured outputs such as JSON, versioned schemas that describe themselves, documentation a machine can retrieve, errors that come back structured and include hints for what to try next, and tools scoped to goals rather than raw create-read-update-delete operations. For an agent, the interface is the product. It has to be honest about what it does, complete about what it returns, and explicit about how it fails.
The core design constraint is context. Agents degrade when you flood them with irrelevant information, so good agent-facing design lets an agent pull only what it needs. It can fetch the current API spec on demand, or filter and paginate a result set, instead of loading everything at once. Managing what fills the context window is the through-line that connects "for agents" design back to how agents actually work, a discipline Anthropic describes as effective context engineering.
Several concrete patterns have emerged for teams designing this way:
- Machine-readable documentation. Conventions like
llms.txtand LLM-friendly doc formats give agents a documentation surface they can parse directly. - Goal-oriented tools over generic endpoints. Fewer, well-described tools built around an outcome, such as
submit_expense_report, serve an agent better than a genericcreate_record. Rich parameter descriptions, scoped permissions, and pagination or truncation that protects the context window all matter. This is the heart of good Model Context Protocol tool design, and of designing APIs for AI agents more broadly. - Observability for agents. Affordances like tracing headers let a team debug what an agent actually did.
- One source of truth for humans and agents. A CLI, API, or doc set that serves a human reader and a machine reader from the same contract keeps both consumers in sync.
Same discipline, inverted user
Agent-centered design continues human-centered design. It points the same craft at a different user.
Human-centered design obsesses over the user's mental model, the points of friction, and the errors people make. Agent-centered design asks the same questions for a user whose cognition is a context window. Know your user. Reduce friction. Design for how they actually process information. The disciplines rhyme.
What changes is the user's constraints, and they invert almost point for point. A human carries memory across sessions, tolerates ambiguity, and rewards visual polish. An agent has finite and fragile context, no persistence by default, and needs explicit structure and deterministic contracts. So the success metric moves too. Human-centered design chases an interface that feels intuitive and delightful. Agent-centered design chases an interface a machine can operate reliably, discover on its own, and recover from when something fails.
At the most fundamental level, the ideal interface for a human and for an agent can converge. A clean "read a file" or "find this in a document" primitive reads well for both. The divergence grows higher up, at the packaging and orchestration layer, where SDKs, plugins, skills, and docs live. That is where designing for an agent shows up most.
The vocabulary is converging: agent experience, agent-native design, and MCP
Agent-centered design is the umbrella over several threads the industry has already started naming, and those threads are converging on the same insight.
The clearest signal is Agent Experience, or AX. Netlify CEO Mathias Biilmann coined the term in January 2025, defining it as the holistic experience AI agents have as the user of a product or platform. He framed AX as the next entry in a lineage of design personas: user experience arrived around 1993, developer experience around 2011, and agent experience now.
The same insight surfaces under other names:
- Agent-native and agent-first design. Software designed from the start to be used by agents, with stable JSON output, structured errors, versioned schemas, and retrievable documentation. The recurring phrase is that the tool surface is the product (Speakeasy; Navya AI).
- Goal-oriented tool APIs. Reconceiving tool interfaces as goal-achievement protocols with built-in governance, rather than form-submission endpoints (Digital API).
- Model Context Protocol. Anthropic's MCP gives agents a standard way to discover and call tools, and its best practices push teams toward fewer, better-described, goal-scoped tools.
- Context engineering. Anthropic's work on context engineering treats what fills the context window as a first-class design problem.
Each thread is describing one part of the same shift. Agent-centered design is the name for the whole of it: both the building side and the consuming side, under one lens.
What it means for builders
First, an honest caveat. Agents are early, and the review loop is a genuine cost. Adopt this lens deliberately, and expect to keep a human in the loop for a while yet.
From there, the practical moves are concrete:
- Treat your API, docs, and error messages as an interface for machine readers as well as human ones.
- Design tools around the goals a caller is trying to reach, and describe them well enough that an agent can choose correctly.
- Make context retrievable on demand instead of dumping everything into the window.
- On the building side, give agents guardrails: scoped permissions, constrained actions, and tests that define what "safe" means before you hand over any autonomy.
The takeaway is a shift in defaults. For thirty years, the safe assumption was that a person would use what you built. That no longer holds. Your next power user may not be human, so design as if it will not be. Agent-centered design is the lens for doing that on purpose, and now is the time to pick it up.
From principle to practice
Principles are easier to state than to live. The best way to understand agent-centered design is to watch a team put it to work on their own software.
The LandingAI engineering team did exactly that. They took these ideas into their own development process, building both by agents and for agents, and used the approach to change how they work and how they shape their codebase.
We wrote up what that looked like from the inside: the guardrails they set, the choices they made, and what shifted along the way. If the concept resonates, the companion story is where it meets real code.