Agent-Native vs. Human-Native: Why Your Knowledge Tool Needs to Be Built for AI From the Start

Confluence and Notion were built for a person at a browser, typing. Making them work for AI agents means rewriting most of the product.

The distinction

Dan Shipper named agent-native architecture as a category and proposed four load-bearing principles:

• Parity – every UI action has a matching tool. UI-only features are incomplete by definition.
• Granularity – tools are atomic. Composition happens in prompts, not in code that pre-composes calls.
• Composability – new capabilities come from new prompts over the existing tool surface, not new code.
• Emergent capability – the tool surface is broad enough that use cases nobody designed for become possible.

In shorthand, a human-native product is built around someone opening a browser, clicking into an editor, and typing. Its API shows up later to support integrations. AI features get bolted on – a summarize button here, a drafting assistant there.

An agent-native product is built around an agent calling a tool. The web UI is where humans review what agents produced. Every write in the dashboard has a corresponding tool; any UI-only action is an unfinished feature.

That isn't a feature difference. It's what the product assumes about who the user is.

The Linear precedent

In Linear's March 2026 "issue tracking is dead" announcement, Karri Saarinen reported that agents now author nearly 25% of new issues, and that the total volume of agent-completed work grew 5× in the preceding three months. 75% of enterprise workspaces had coding agents installed.

Linear is arguably the most modern project management tool on the market – API-first, keyboard-first, built by people who care about the primitive. And even Linear had to retrofit: Linear Agent, Skills, and Automations all shipped in that March release, extending a product originally designed for a human typing into a form.

Linear's retrofit is the comparatively easy case: their GraphQL API is already action-oriented, their permission model is principled, and their culture ships primitives. Confluence and Notion are harder cases because their APIs are resource-CRUD (pages, spaces, blocks) rather than intention-verb, their permission models are baked into a UI-centric metaphor, and their pricing is per-seat end-to-end.

Confluence's AI features (AI pages, AI summaries) are built around human workflows enhanced by AI, not around agent-authored content as the primary input. Notion sits in the same position. Both have hosted MCP servers that support reads and writes – but having an MCP endpoint doesn't make you agent-native any more than having a REST endpoint makes you API-native.

Why retrofitting is structurally hard

Product architecture – tools shaped by verbs, not resources. Cloudflare's Code Mode research found that agents reason better over small, action-oriented tool surfaces than over large CRUD-style endpoint lists: two tools covered 2,500+ operations. Our public MCP tool surface is seven verbs: publish, share, rename, find, get, export, delete. A CLI invocation (dsp publish ./report.html) and an MCP invocation of the publish tool hit the same underlying operation. Confluence's API exposes /content, /space, /user, /group – resource-CRUD. Retrofitting an agent-native surface means reshaping the API's verb vocabulary, not just adding an MCP adapter on top.

Katie Parrott documents a related constraint from Sparkle's Yash Poojary: agent guardrails have to live in the tools, not in the system prompt. Sparkle moved file-deletion confirmation out of a prompt rule and into the delete tool itself after the agent began skipping confirmations. The pattern generalizes – retrofitting a human-first editor to be safe for agents means auditing every mutating surface and moving constraints from UI modals into tool-layer contracts.

Identity and audit. Every display.dev API request carries an X-Client-Type header that normalizes into an indexed source column on every audit row – one of cli, mcp, dashboard, api, worker, or webhook. A compliance officer can filter agent-driven publishes from human-driven ones with one SQL predicate. Confluence's audit log records actor, event type, object; nothing distinguishes "a human typed into the editor" from "an agent called the REST API with the same user's credentials." Retrofit: pick a header convention, backfill the schema, rebuild the audit-query UI.

Authorization and tool discovery. A display.dev MCP client connecting as a member sees a member-scoped tool list. An admin client sees that plus administrative tools – keys, members, settings, audit log, analytics. Members don't receive 403s on admin calls; the admin tools aren't in their discovered list at all. On top of role-gating, API keys can be scoped to specific tools at creation – an agent key with scope publish, find cannot delete or modify settings regardless of the user's role, and scope enforcement is per-request (a call outside scope returns 403). Human-first permission models, built around per-resource ACLs mapped to UI roles, don't cleanly translate to "which tools should appear in this agent's MCP discovery response?"

Review gates and the workflow contract. Human-first products assume draft → review → publish. Agent-first products assume publish → humans review in the dashboard. The first model puts a human gate in front of every artifact an agent produces; the second lets an agent publish unattended and surfaces the artifact for humans to scan asynchronously. As agent authorship rises – at Linear it's already nearly 25% of new issues – the first model becomes a throughput bottleneck. The second requires the viewer side (dashboard, audit log, shareable URLs) to carry the review weight. Retrofitting the second onto the first breaks existing customers' workflow expectations.

Business model. Per-seat pricing punishes agent-heavy usage. An agent publishing at volume creates viewer demand – humans reading what the agent produced – that per-seat pricing then charges for. Our pricing is flat per organization (not per seat, not per artifact, not per viewer), because the unit economics assume agent volume, not human authorship volume. Adding flat pricing on top of an existing per-seat book cannibalizes revenue.

AI strategy. Notion AI and Confluence AI are proprietary AI products; they keep you inside their surface using their AI. Multi-agent neutrality – supporting Claude Code, Cursor, Codex, and whatever comes next equally – undermines the feature they're actually selling. The two positions don't coexist.

What agent-native means in practice at display.dev

CLI, MCP, and REST hit the same function. The CLI subcommand name is the MCP tool name (publish), and both call the same REST endpoint. No translation layer, no feature drift between surfaces.

dsp publish ./research-dossier.html --visibility company

// MCP tools/call — "name" is the tool name, "arguments" are the tool args
{
  "name": "publish",
  "arguments": {
    "content": "<html>…</html>",
    "name": "research-dossier-2026-04-22",
    "visibility": "company"
  }
}

Both produce the same artifact, same URL, same audit row.

Audit distinguishes agent from human. A representative audit row:

{
  "action": "artifact.publish",
  "actor": "[email protected]",
  "source": "mcp",
  "object": "artifact:ab12cd34"
}

source: mcp tags this as agent-driven. A dashboard upload tags source: dashboard; a CI push tags source: cli or source: api depending on the authentication path. Downstream compliance queries filter on one indexed column.

Role-gated tool discovery. When an MCP client connects, the server validates the credential, resolves the user's role, and returns a role-filtered tool list. A member sees read/publish/own-artifact tools. An admin sees those plus administrative tools for keys, members, settings, audit log, and analytics. The tool list itself is personalized; members literally cannot enumerate admin tools.

Scoped keys. Keys can be issued with tool-scope restrictions at creation. A CI/CD key scoped to publish can only publish. An analyst's agent key scoped to find, get can only read. Scope is enforced per-request: exceeding scope returns 403 regardless of the user's role. Agents running on third-party infrastructure often have broader system access than the user intended, and per-key scoping is how we close that gap.

Every new agent is another publisher

Human-native tools with bolted-on AI features tie themselves to a specific vendor. If your AI features are built around OpenAI, you have a problem when Anthropic pulls ahead on the benchmarks your team cares about. If they're built around Anthropic, you have the same problem in reverse. Frontier leadership has changed hands repeatedly since 2023; there's no reason to bet it stops.

Agent-native tools are substrate-agnostic. They don't bet on which model wins; they provide the layer every agent writes into. Every new agent, every new model, is a potential publisher. The more AI tools proliferate, the more valuable the substrate becomes.