Agent-native Architecture
What it is
Agent-native architecture designs software so agents can pursue outcomes by operating tools, state, files, and workflows directly. The core shift is from “features as hard-coded UI flows” to “capabilities exposed as agent-usable primitives”. Humans still use the product, but agents become first-class operators.
Why it matters
Adding a chatbot to existing SaaS does not make it agent-native. A product becomes agent-native when agents can inspect state, take actions, recover from edge cases, and combine primitives in ways the product team did not pre-program. This is the architecture behind Claude Code-like workflows, Codex-native apps, and agent-ready enterprise software.
Evidence across sources
- Every’s agent-native architecture essay defines the pattern through parity, granularity, composability, emergent capability, and improvement over time.
- Dan Shipper’s “Claude Code in a trench coat” framing shows a product that looks like normal software but routes work through an underlying agent.
- Later Codex-native / Cowork-native / Cursor-native examples show the same principle applied to apps embedded inside agent browsers and workspaces.
- Stainless/MCP adds a lower-level design constraint: agent-native products need APIs, SDKs, and MCP tools that are narrow, well-named, typed enough to inspect, and recoverable when calls fail.
- Google I/O 2026 shows the platform version of the same architecture: Search, Workspace, Spark, Antigravity, and managed agents turn model capability into distributed product surfaces.
- AINews and The Rundown reports around Google I/O add a second lens: agent-native architecture is becoming a platform distribution strategy, not only an app design pattern.
Core principles
- Parity：用户能通过 UI 完成的事，agent 也应能通过工具完成。
- Granularity：工具应是小而原子的 primitives，复杂功能应由 agent/skill 组合出来。
- Composability：原子工具和技能可以组合出团队没有显式设计过的新功能。
- Emergent capability：用户提出开放式目标时，agent 能探索工具组合，而不是只路由到既有按钮。
- Improvement over time：应用通过 context、skills、prompt、observed demand 持续改进。
MCP and code-as-interface layer
The Stainless source adds a sharper implementation rule: exposing every API endpoint as a tool is not agent-native architecture. For complex services, the better interface may be:
- a small set of named tools with tightly scoped outputs;
- an SDK or typed client that an agent can call inside a sandbox;
- documentation search that lets the agent discover the right primitive;
- permission and auth boundaries that live in the product/API layer rather than only in prompt text.
This reframes headless mode as more than API coverage. Agent-native products need machine-operable state, clear failure modes, recoverable actions, and human-readable audit trails.
Product tests
- 任取一个 UI 操作，agent 是否有等价工具路径？
- 描述一个没有显式开发的领域任务，agent 能否组合现有 primitives 完成？
- 不可逆操作的确认是在工具代码里强制，还是只写在 prompt 里？
- 如果要改变行为，是编辑 skill/prompt，还是必须改产品代码？
- Agent 的工作产物是否对人可检查、可恢复、可审计？
Open questions
- 原子工具和领域工具的最佳边界在哪里？
- 哪些高频路径应从 agent orchestration "毕业"到确定性代码？
- Agent-native 是否会让文件系统和 CLI 重新成为产品架构的核心接口？
2026-05-28 更新：Agent 产品设计的"谁主导"范式
宝玉 dotey 提出 Agent 产品的界面布局应取决于产品定位：
- 以人为主：工作区居中，Agent 辅助在右侧。典型场景如 Google Slides 中自己编辑，右侧随时与 Agent 对话辅助
- 以 Agent 为主：Agent 对话区居中，工作区在右侧。典型场景如 Codex App、Claude Desktop、Cursor Agent——用户主要指挥 Agent，不需要直接操作工作区
主流 Agent 产品（Codex App、Claude Desktop、Cursor Agent）均采用"Agent 对话区居中"布局。这代表 Agent-native 产品正在从"在人类界面旁加一个 chatbot"走向"以 Agent 为操作核心"的范式转移。设计 Agent 产品时应首先明确"谁主导"这一核心问题。
链接：https://x.com/dotey/status/2059666423538983242