# Agent Native: full site

> The complete content of https://agentnative.build as one Markdown file. Index: https://agentnative.build/llms.txt

# What Is Agent-Native Software? Definition & Scorecard

> Agent-native software is software designed so an AI agent is a first-class user: it can discover the product, understand it, act in it, be limited inside it, and verify what happened, without a human translating. It is not a chatbot bolted on, and not a scraper in disguise.

URL: https://agentnative.build/ · By Mark Hinkle · Updated 2026-10-21
Machine-readable index: https://agentnative.build/llms.txt

## What does agent-native mean?

The human is still in the loop, but at the points that matter: approval, oversight, and outcomes. Not at every click.

Cloud-native meant designing for the datacenter you actually run on. Mobile-native meant designing for a thumb and a small screen. Agent-native means designing for a reader that is fast, literal, tireless, token-limited, and has no eyes.

### Three stages

|  | Agent-bolted-on | Agent-ready | Agent-native |
|---|---|---|---|
| Interface | Chat widget over the same UI; agents drive a browser | Public API, partial coverage | Every capability is a tool, API, or CLI call; the UI is one client of many |
| Docs | PDFs, videos, marketing pages | Human docs plus an OpenAPI file | llms.txt, clean Markdown, schemas with examples, tool descriptions written for models |
| Auth | Shared human login, CAPTCHA | API keys, coarse scopes | Delegated, scoped, revocable agent identities with spend and rate limits |
| Errors | HTML pages, “something went wrong” | JSON with a status code | Code, cause, fix, and a retryable flag |
| State changes | Fire and hope | Sometimes idempotent | Idempotency keys, dry-run, receipts |
| Verification | Eyeball it | Logs for engineers | Queryable receipts; actor recorded as human or agent |

## What are the principles of agent-native design?

1. **Parity.** Anything a person can do in the UI, an agent can do through a stable interface. If the only way in is a button, the product is not agent-native.
   - Bolted-on: A “Refund” button with no endpoint behind it.
   - Native: Refund is a tool; the button calls the same tool.
2. **Legibility.** Schemas, examples, and tool descriptions are written so a model can pick the right call without a human reading the docs first.
   - Bolted-on: Docs live in a video and a PDF. The agent guesses.
   - Native: Schemas, examples, and tool descriptions written for models, plus llms.txt.
3. **Idempotent by default.** Writes accept idempotency keys, costly actions offer dry-run, and side effects are stated up front.
   - Bolted-on: A timeout, a retry, and the customer is refunded twice.
   - Native: Idempotency key on every write; dry_run on costly calls.
4. **Errors that teach.** Return a machine-readable code, the cause, a suggested fix, and whether a retry can succeed.
   - Bolted-on: “Something went wrong” in an HTML page.
   - Native: {code, cause, fix, retryable}. The agent corrects itself.
5. **Scoped authority.** Least privilege, delegated tokens, spend caps, and human approval gates for irreversible actions.
   - Bolted-on: The agent borrows the owner’s full-power login.
   - Native: Per-agent identity, narrow scopes, spend caps, approval on irreversible actions.
6. **Verifiable.** Every action returns a receipt and lands in an audit log. Agents can check their own work, and humans can check the agents.
   - Bolted-on: No record of who or what clicked the button.
   - Native: A receipt per action and an audit log that records human vs agent.
7. **Context-thrifty.** Support pagination, field selection, and concise formats. Prefer Markdown to markup soup.
   - Bolted-on: A 4,000-row response and 90% markup.
   - Native: Pagination, field selection, Markdown, and summaries on request.
8. **Composable.** Small primitives with text in and text out (CLIs, files, narrow tools) that agents can chain in ways you did not plan for.
   - Bolted-on: One monolithic “do everything” endpoint.
   - Native: Narrow tools and CLIs with text in, text out, ready to chain.

## Same task, three readers: "refund order #1042"

**A person** (failure risk: Low). Works, because the UI was built for eyes and a mouse.
1. Log in
2. Search orders (type “1042”)
3. Open order #1042
4. Click Refund
5. Choose a reason (dropdown)
6. Confirm amount
7. Confirm again (modal)

**Bolted-on agent** (failure risk: High). Sometimes works. Nobody can say whether it refunded twice.
1. Screenshot the login page
2. Guess the password field selector
3. Dismiss cookie banner
4. CAPTCHA: verify you are human (blocked)
5. Retry from the top
6. Parse the HTML orders table (column order changed)
7. Click Refund (modal not found)
8. Retry click (unknown: did it fire twice?)

**Agent-native** (failure risk: Low). Deterministic, previewed, retry-safe, and verified.
1. Read tool schema (refund_order(order_id, amount, reason, dry_run, idempotency_key))
2. refund_order(dry_run: true) (preview: refund 80.00 to card ••4242)
3. refund_order(idempotency_key: "a1f9…") (receipt: {refund_id: "rf_77", status: "succeeded"})
4. get_refund("rf_77") (verified: succeeded, actor: agent)

Illustrative example, not a benchmark.

## What does an agent-native product look like?

1. **Discover**: llms.txt · AGENTS.md · Markdown pages · clean sitemap
2. **Describe**: OpenAPI · JSON Schema · MCP tool definitions written for models
3. **Act**: API · CLI · MCP server · packaged skills, with UI parity
4. **Authorize**: Narrow scopes · per-agent identity · spend limits · approval gates
5. **Verify**: Receipts · audit log · actor attribution · evals in CI

Example llms.txt:

```
# Acme Payments
> Payments API. Refunds, charges, disputes.
> Start with /docs/quickstart.md

## Docs
- [Quickstart](/docs/quickstart.md): first charge in 5 calls
- [Errors](/docs/errors.md): every code and its fix

## Optional
- [Changelog](/changelog.md)
```

Example error an agent can act on:

```json
{
  "error": {
    "code": "refund_exceeds_balance",
    "message": "Refund 120.00 exceeds refundable 80.00.",
    "fix": "Retry with amount <= 80.00.",
    "retryable": false
  }
}
```

## How agent-native is your product? A 12-question scorecard

One point per yes. 0-3: Agent-hostile; 4-6: Agent-tolerant; 7-9: Agent-ready; 10-12: Agent-native.

1. Everything a user can do in the UI is available through an API, CLI, or tool interface.
2. Interfaces are described machine-readably (OpenAPI, JSON Schema, MCP).
3. There is an llms.txt or equivalent, and docs are available as clean Markdown.
4. Write operations accept idempotency keys.
5. Destructive or costly actions support dry-run or preview.
6. Errors are structured, with a code, cause, and suggested fix.
7. Agents can get scoped credentials without a human clicking through each session.
8. Spend, rate, and permission limits can be set per agent identity.
9. Every action returns a receipt or lands in an audit log an agent can query.
10. Responses support pagination, field selection, and concise formats.
11. You can tell whether a human or an agent performed an action.
12. Agents are tested against the product (evals or CI), not just humans.

## Agent-washing: what to avoid

- **The corner chatbot** that no other agent can call.
- **CAPTCHA walls** in front of a legitimate workflow with no API behind them.
- **Docs as PDFs or video,** or pages that only exist after JavaScript runs.
- **Errors as HTML** pages.
- **OAuth that needs a human click** on every call.
- **Infinite scroll** as the only way to get a list.
- **The human’s full-power login** handed to the agent “to keep it simple”.

## How we got here

- **2023.** Function calling and plugins let models call developer-defined tools.
- **2024.** llms.txt is proposed as a model-readable site index; Anthropic introduces the Model Context Protocol.
- **2025.** AGENTS.md and agent skills spread as ways to hand agents project and procedural context; coding agents make “agent as user” routine.
- **Now.** Products get judged on how well agents can use them, not just people.

## Go deeper

- [The future of interfaces: MCP, MCP Apps, WebMCP, conversational UI](https://agentnative.build/future)
- [Examples: ConferenceOS, Agent Kontrol, Cortex](https://agentnative.build/examples)

## Questions

**Is agent-native just having an API?** An API is necessary, not sufficient. Agent-native adds self-description, safe retries, teaching errors, scoped delegated authority, and verification.

**Do humans get worse software when it is agent-native?** No. Clear errors, undo, audit trails, and least privilege make products better for people too.

**What is the difference between agent-native and AI-native?** AI-native usually describes products that use AI inside the experience. Agent-native describes products that AI agents can operate: discoverable, callable, limited, and verifiable. A product can be either, neither, or both.

**Where do I start making a product agent-native?** Take the scorecard, pick the lowest-scoring principle, and fix it for your single most-used workflow.

---

# MCP, MCP Apps, WebMCP & Conversational UI: What's Next

> Interfaces are splitting into three layers that share one set of tools. MCP exposes capabilities to agents, MCP Apps lets those agents summon real UI inside a conversation, and WebMCP lets a web page offer tools to the browser’s agent. Conversation becomes the front door. Forms do not disappear; they become the place you review and commit.

URL: https://agentnative.build/future · By Mark Hinkle · Updated 2026-10-21
Machine-readable index: https://agentnative.build/llms.txt

## What is MCP, and why does it matter for agent-native software?

> The Model Context Protocol (MCP) is an open protocol for connecting AI applications to tools and data. Build your product’s capabilities once as MCP tools and any compatible agent can use them.

Anthropic introduced MCP in November 2024 and donated it to the Linux Foundation’s Agentic AI Foundation on December 9, 2025, so it now has vendor-neutral governance [[6]](#src-6). The published 2026-07-28 specification describes stateless, self-contained requests with per-request capability negotiation, and lists Tasks, Skills over MCP, and MCP Apps as optional extensions [[1]](#src-1). The release post adds a formal extensions framework and hardened authorization [[2]](#src-2).

For product teams, MCP is the “Act” layer in the [anatomy of an agent-native product](/#anatomy). It is where parity, scoped authority, and receipts get implemented.

## What are MCP Apps?

> MCP Apps is the first official extension to MCP. A tool can return an interactive HTML interface, declared ahead of time, which the host renders in a sandboxed iframe inside the chat [[3]](#src-3).

It went live on January 26, 2026, and the announcement names Claude, ChatGPT, Goose, and Visual Studio Code among supporting clients [[3]](#src-3); coverage varies by client. This is what makes conversation *functional*: the agent can ask for a date range in plain language, then show a real picker, a diff, a chart, or an approval card when precision matters.

> **Why it matters.** Before MCP Apps, a conversational product had two weak options: make the user type everything, or send them to another tab. Now the interface can arrive inside the conversation, exactly when it is needed.

## What is WebMCP?

> WebMCP is a proposed browser API that lets a web page expose JavaScript functions as tools to AI agents. It is a Draft Community Group Report from the W3C Web Machine Learning Community Group, authored by people at Google and Microsoft. It is not a finished standard [[4]](#src-4).

The proposal describes an *imperative* API, where the page registers tools in JavaScript, and a *declarative* approach for standard actions defined in HTML forms. Tools run in the page, in the user’s own session, and the browser mediates consent [[4]](#src-4). Secondary reports say Chrome began an early preview in February 2026; support in other browsers is unconfirmed.

> **Try it here.** This site registers its own WebMCP tools when your browser supports the API, and also runs a remote MCP server. See [every agent surface on this site](/agents).

*Illustrative, based on the proposal. Naming has shifted between drafts: check the current spec before building.*

```
navigator.modelContext.registerTool({
  name: "add-to-schedule",
  description: "Add a session to the attendee's personal schedule",
  inputSchema: {
    type: "object",
    properties: { sessionId: { type: "string" } },
    required: ["sessionId"]
  },
  async execute({ sessionId }, agent) {
    await agent.requestUserInteraction(() => confirmDialog(sessionId));
    return { content: [{ type: "text", text: "Added " + sessionId }] };
  }
});
```

### MCP, MCP Apps, WebMCP, and the rest: which is which?

| Layer | Runs where | What it does | Status |
|---|---|---|---|
| llms.txt | A file on your site | Indexes your content for models | Community convention |
| OpenAPI / JSON Schema | Your API | Describes endpoints and shapes | Mature |
| MCP | A server you run | Exposes tools, resources, prompts to any agent | Open spec; Linux Foundation |
| MCP Apps | Inside the AI client | Returns interactive UI from a tool | Official extension |
| WebMCP | Inside the web page | Page offers tools to the browser agent, using the user’s session | Draft proposal |

They are complements. A server-side MCP tool works when no browser is open. A WebMCP tool works because the user is already signed in and looking at the page. Many products will want both, backed by the same business logic.

## Will conversational interfaces replace forms?

> No. Conversation is best for stating intent and exploring options. Structured UI is best for review, precision, and commitment. Design the conversation as an additional front door, with the form still there as the place to verify and the fallback when talking is slower.

Forms are not a failure mode; they are compressed knowledge about what a system needs. A conversational layer that discards that knowledge produces ambiguity, so the better pattern is to use conversation to *fill in* the structure.

## How do you make a conversational interface functional, not just chatty?

> Put the same tools under both the chat and the UI, have the agent produce a structured proposal, and require a visible confirmation before anything irreversible. These six patterns are design guidance, not a standard.

1. **One set of tools.** The chat, the buttons, and any outside agent all call the same operations. If the chat can do something the UI cannot (or the reverse), you have two products.
2. **Intent in, proposal out.** The user says “move the keynote to Thursday.” The agent returns a typed change set (what, where, what it affects), not a paragraph.
3. **Chat plans, UI commits.** Render the proposal as an approval card with a diff. The user confirms with a click. This is where MCP Apps earns its keep.
4. **Dry-run before write.** Every costly or destructive tool supports preview, so the proposal is real, not a guess.
5. **Keep the escape hatch.** Every conversational flow links to the equivalent form with fields pre-filled. Power users and edge cases need it.
6. **Receipts and undo.** After the action, show what happened, who did it (human or agent), and how to reverse it.

## What should you do this quarter?

1. Publish `/llms.txt` and Markdown versions of your key docs.
2. Expose your single most-used workflow as an MCP tool with a schema, dry-run, and idempotency key.
3. Add structured errors and receipts to that workflow.
4. Add one approval card via MCP Apps for the riskiest action.
5. Prototype WebMCP behind a flag on one page, and treat it as an experiment.
6. Test with real agents. Watch where they fail, and fix the interface, not the prompt.

See how we apply this in the [shipped examples](/examples), then [score your own product](/#score).

## What is still uncertain?

- **WebMCP’s API surface.** Secondary sources disagree on whether the entry point is `navigator.modelContext` or a document-level property, and the official proposal page uses an older shape. Check the spec.
- **Browser support.** Chrome’s preview is reported; Firefox and Safari commitments are not confirmed in the sources we found.
- **MCP Apps host coverage.** Support varies by client and is changing quickly.
- **Standards drift.** MCP’s 2026-07-28 release deprecates Roots, Sampling, and Logging (deprecated, not removed) [[2]](#src-2). Build against the current spec, not a blog post.

## Frequently asked questions

**What is MCP?** The Model Context Protocol is an open protocol for connecting AI applications to tools and data. Anthropic introduced it in November 2024 and donated it to the Linux Foundation’s Agentic AI Foundation in December 2025.

**What are MCP Apps?** MCP Apps is the first official MCP extension. It lets a tool return an interactive HTML interface that the host, such as Claude or ChatGPT, renders in a sandboxed frame inside the conversation.

**What is WebMCP?** WebMCP is a proposed browser API that lets a web page expose JavaScript functions as tools for AI agents. It is a draft from the W3C Web Machine Learning Community Group, not a finished standard.

**Will conversational interfaces replace forms?** No. Conversation is best for stating intent and exploring options. Structured interfaces are best for review, precision, and commitment. The strongest products use both over the same underlying tools.

## Sources

1. [Model Context Protocol Specification, version 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28), modelcontextprotocol.io
2. [The 2026-07-28 MCP Specification Release Candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/), Model Context Protocol blog
3. [MCP Apps: bringing UI capabilities to MCP clients (2026-01-26)](https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/), Model Context Protocol blog
4. [WebMCP API Proposal](https://webmachinelearning.github.io/webmcp/docs/proposal.html), W3C Web Machine Learning Community Group
5. [WebMCP Technical Notes](https://w3c-cg.github.io/aikr/webMCP/webmcp-technical-notes.html), W3C Community Group
6. [Model Context Protocol (governance timeline)](https://en.wikipedia.org/wiki/Model_Context_Protocol), Wikipedia

Dates and status reflect sources read on 2026-10-21. The MCP and MCP Apps claims were checked against the primary pages above. Chrome’s WebMCP preview comes from secondary reports. Verify details before relying on them.

---

# Agent-Native Examples: ConferenceOS, Agent Kontrol, Cortex

> Three projects we build and run show different faces of agent-native: ConferenceOS (a product agents operate), Agent Kontrol (the control room for the agents themselves), and Cortex (memory every agent shares). Each is described with what is real today and what is still being built. These are self-reported.

URL: https://agentnative.build/examples · By Mark Hinkle · Updated 2026-10-21
Machine-readable index: https://agentnative.build/llms.txt

## ConferenceOS: conference management software that agents can run

> ConferenceOS is an open source (Apache-2.0) conference operating system, positioned as AI-native and agent-run. Event teams hand repetitive work and plain-language requests to authorized agents and keep control of sensitive actions.

- **Built for:** Running events: registration, attendees, speakers, sponsors, and onsite check-in. It runs the All Things AI conference and is the proof point for the platform.
- **Scoped authority:** Role-based access control with six roles (Attendee, Organizer, Admin, Sponsor, Volunteer, Partner), each with distinct permissions and views. An agent acts inside a role, not as an all-powerful login.
- **Parity:** The goal is that what an organizer does by hand is something an authorized agent can do, so the UI is one client of many.
- **Conversational, additive:** Plain-language requests sit on top of the structured system; sensitive actions still require a human checkpoint.
- **Still exploring:** A sponsor team calendar, driven by an agentic chat planner, is an idea on the backlog and is not shipped. Sponsor teams currently coordinate rooms and shifts over texts and spreadsheets, which is the kind of messy intent conversation handles well.

## Agent Kontrol: governing and observing a fleet of AI agents

> Agent Kontrol is an open source control room for a fleet of agents running across multiple machines and vendors. It combines a task queue and a backlog board with a global attention strip that shows what needs a human right now.

- **Built for:** People who run several coding agents at once and need one place to see state, queue work, and spot what is blocked.
- **Scoped authority:** Doctrine learned the hard way: one coordinator, one reviewer from a different vendor, deterministic gates, a human on exceptions, and no agent approves another agent’s permission prompts.
- **Verifiable:** An attention strip sorted by urgency, and usage headroom shown honestly: an unknown quota never reads as zero.
- **Why it matters:** As agents become users of everything, someone has to govern and observe the agents. That is its own product category, often called agent governance and agent observability.

## Cortex: memory that every agent reads

> Cortex is a shared memory service exposed over MCP, so Claude, Codex, Grok, and Hermes read the same distilled facts instead of each keeping private notes.

- **Built for:** Continuity across sessions and across vendors: decisions, findings, and state written once and recalled anywhere.
- **Legibility:** Facts are atomic, self-contained, and carry their source, so a cold agent can use them without the original conversation.
- **Composable:** Small MCP tools (recall, search, remember) that any client can call. MCP OAuth support broadens compatibility with clients that only speak OAuth.

## What do the three have in common?

1. **Agents are users from day one,** not added after launch.
2. **Authority is scoped,** and humans keep the irreversible decisions.
3. **Everything is legible to a cold reader:** structured, sourced, and written down.
4. **Conversation sits on top of structure,** never instead of it.

Compare your own product with the [12-question scorecard](https://agentnative.build/#score), or read about [where interfaces are heading](https://agentnative.build/future).

## Frequently asked questions

**What is an example of an agent-native product?** ConferenceOS is an open source conference operating system built so authorized AI agents can run event operations through plain-language requests while humans keep control of sensitive actions.

**What is Agent Kontrol?** Agent Kontrol is an open source control room for a fleet of AI agents across machines and vendors, with a task queue, a backlog board, and a global “needs you” attention strip.

**What is Cortex?** Cortex is a shared memory service exposed over MCP so different agents, including Claude, Codex, Grok, and Hermes, read the same distilled facts.

---

# How This Site Is Agent-Native: WebMCP, MCP, llms.txt

> This site practices what it teaches. It exposes the same content and tools through seven surfaces so an agent can find it, read it, and act on it. The content is public and read-only, so none of the surfaces need authentication. A product that changes state would add the scoped-authority layer on top.

URL: https://agentnative.build/agents · By Mark Hinkle · Updated 2026-10-21
Machine-readable index: https://agentnative.build/llms.txt

## What surfaces does this site expose to agents?

> Seven: an llms.txt index, a single-file llms-full.txt, Markdown twins of every page, Markdown content negotiation on the normal URLs, a remote MCP server, WebMCP tools registered in the page, and JSON-LD structured data.

| Surface | Where | What an agent gets |
|---|---|---|
| llms.txt | /llms.txt | A short index of pages, one line each |
| llms-full.txt | /llms-full.txt | The whole site as one Markdown file, for a single fetch |
| Markdown twins | /index.md, /future.md, /examples.md, /agents.md | Each page as clean Markdown |
| Content negotiation | Any page with `Accept: text/markdown` | The same URL, answered as Markdown |
| Remote MCP server | /api/mcp | Five read-only tools over JSON-RPC |
| WebMCP tools | In the page, via `navigator.modelContext` | The same tools plus reader-view and navigation control, for browser agents |
| Structured data | JSON-LD in each page head | Article, FAQPage, and BreadcrumbList |

## What is the difference between llms.txt and llms-full.txt?

> llms.txt is a short Markdown index that tells a model which pages exist and where to find clean versions. llms-full.txt carries the full content inline, so an agent can load the entire site in one request.

Both are community conventions, not standards. Support from search engines and model providers is not confirmed, so treat them as a low-cost courtesy to agents and developer tools that do read them, not as a ranking lever.

## Which WebMCP tools does this page register?

> When the browser exposes the WebMCP API, the page registers seven tools. Five mirror the MCP server and two control the page itself. If the API is absent, nothing is registered and the page works as normal.

- `get_definition`: the definition of agent-native software.
- `list_principles`: the eight design principles with bolted-on and native examples.
- `score_product`: takes twelve yes or no answers and returns the score, tier, and the gaps to close.
- `get_page`: any page as Markdown.
- `search_site`: keyword search across every page.
- `set_reader_view`: switch the page between the human view and the agent view.
- `open_page`: navigate to a page on this site.

> **Status.** WebMCP is a draft proposal. The entry point has shifted between drafts, so the page checks for both `navigator.modelContext` and `document.modelContext` and registers nothing if neither exists.

## How do I call the MCP server?

> Send JSON-RPC 2.0 over HTTP POST to https://agentnative.build/api/mcp. Every request is self-contained: there is no session, and no handshake is required before calling a tool.

*List the tools*

```
curl -s https://agentnative.build/api/mcp   -H 'content-type: application/json'   -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

*Score a product (first four answers yes)*

```
curl -s https://agentnative.build/api/mcp   -H 'content-type: application/json'   -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
    "name":"score_product",
    "arguments":{"answers":[true,true,true,true,false,false,false,false,false,false,false,false]}}}'
```

## How does Markdown content negotiation work?

> Request any page with an Accept header that prefers text/markdown and the server answers with the Markdown twin at the same URL. Browsers still get HTML.

*Same URL, different representation*

```
curl -s -H 'Accept: text/markdown' https://agentnative.build/future
```

## What is deliberately not here?

- **Declarative WebMCP.** The proposal marks the form-based syntax as to be determined, so only the imperative API is used.
- **Authentication.** The content is public and read-only. Write tools would need scoped, per-agent credentials.
- **Server discovery metadata.** Discovery conventions for MCP servers are still moving, so none is published yet.
- **Write tools.** Nothing on this site changes state, so there is nothing to approve, undo, or audit.

## Frequently asked questions

**What is llms-full.txt?** A single Markdown file that contains the full content of a site, so an agent can load everything in one request. It is a community convention that complements the shorter llms.txt index.

**Does this site have an MCP server?** Yes. A read-only remote MCP server runs at https://agentnative.build/api/mcp and exposes five tools: get_definition, list_principles, score_product, get_page, and search_site.

**Does this site support WebMCP?** Yes, when the browser exposes the WebMCP API. The page registers seven tools through navigator.modelContext and registers nothing otherwise.