Agent-Native: Define an Action Once, Ship It as UI, Agent, MCP, and CLI

AI Agent Frameworks Compared: LangChain vs CrewAI vs AutoGen vs LlamaIndex vs LangGraph • MCP Server Security: 10-Server Production Stack

What Is Agent-Native? #

Agent-Native is Builder.io’s answer to a specific duplication problem: teams building “AI-powered apps” often end up maintaining a UI-facing API, a separate agent/tool-facing API, and sometimes a third CLI-facing interface for the same underlying business logic. Agent-Native’s pitch is one primitive that removes that duplication — “don’t pick between apps or agents. Agent-Native apps are both.”

🔗 GitHub: https://github.com/BuilderIO/agent-native 🌐 Docs: agent-native.com

MIT licensed, at 4,300+ GitHub stars, with a commit from August 2, 2026 — the day before this article — from Builder.io, a company already well known in the web/CMS tooling space.

The Core Primitive: defineAction() #

// One action powers every app surface: UI, agent, HTTP, MCP, A2A, and CLI.
export default defineAction({
  schema: z.object({
    emailId: z.string(),
    body: z.string(),
  }),
  run: async ({ emailId, body }) => {
    await db.insert(replies).values({ emailId, body });
  },
});

Define the work once — a Zod schema for inputs and a run function for the logic — and that single definition is automatically callable from:

• UI — a form or button in your web app
• HTTP — a REST-style API endpoint
• MCP — a tool an MCP-compatible agent (Claude Code, Cursor, etc.) can call
• A2A — an endpoint another agent can call directly, agent-to-agent
• CLI — a command a developer or a script can invoke

The point isn’t just “less code” — it’s that the UI and the agent are calling the exact same validated, typed action, so they can’t silently drift out of sync the way a hand-maintained UI API and a hand-maintained agent-tool API eventually do.

What Ships With the Framework #

Beyond action routing, four pieces are documented as part of the core:

• Actions — define work once, use it from every surface
• Agent runtime — chat, tools, skills, memory, jobs, observability, and handoffs, shipped together rather than assembled from separate packages
• Backend agnostic — any Drizzle-ORM-supported SQL database, any Nitro-compatible host
• Toolkits — reusable building blocks for collaboration, sharing, settings, teams, and observability

Quick Start #

npx @agent-native/core@latest create my-app
cd my-app
pnpm install
pnpm dev

Flags skip the interactive prompt for common starting points:

npx @agent-native/core@latest create my-app --template chat
npx @agent-native/core@latest create my-app --headless
npx @agent-native/core@latest create my-app --standalone

The framework’s suggested workflow isn’t “start from a blank slate” — it’s start from a working template, then let the agent evolve it, since every template is a fully customizable Agent-Native app rather than a static demo.

Example Templates #

The full gallery is at agent-native.com/apps; each template is a real starting point via the create CLI, not just a screenshot.

Agent-Native vs. Bolting an Agent Onto an Existing App #

Use Cases #

1. Apps Where the Agent Should Do Exactly What the UI Can Do #

If a human can click a button to do something, and you want an agent to be able to do the same thing safely, defining it once as an Action means the agent’s capability and the UI’s capability can never diverge — they’re the same code.

2. Exposing Internal Tools to Both Humans and Coding Agents #

An internal admin action (say, “reply to a support ticket”) defined as an Agent-Native Action is simultaneously a UI button for a human agent and an MCP tool a coding agent (or a support-automation agent) can call — without maintaining two implementations.

3. Building on a Template Instead of From Scratch #

The create CLI’s template flags (--template chat, etc.) are aimed at getting a working agent-native app running in minutes, then customizing from there, rather than assembling an agent runtime, a database layer, and an MCP server from separate libraries.

4. Multi-Agent (A2A) Systems Without a Separate Protocol Adapter #

Because A2A is one of the surfaces an Action serves natively, building a system where multiple agents call into each other’s actions doesn’t require a bespoke agent-to-agent protocol layer on top of the framework.

Related Repositories #

Related Articles #

• AI Agent Frameworks Compared: LangChain vs CrewAI vs AutoGen vs LlamaIndex vs LangGraph — for comparing Agent-Native’s single-action-multi-surface model against orchestration-first frameworks
• MCP Server Security: 10-Server Production Stack — relevant once an Agent-Native app’s Actions are exposed as MCP tools in production

Conclusion #

Agent-Native targets a real, specific pain: as soon as an app needs both a UI and an agent-callable surface, most teams end up maintaining two parallel APIs that quietly drift apart. Collapsing that into one defineAction() definition — serving UI, HTTP, MCP, A2A, and CLI from the same schema and the same run function — is a clean architectural bet, backed by a real template gallery rather than just a concept diagram. The README itself is light on deep API reference (most detail lives on agent-native.com/docs), so budget time to read the docs site alongside the code if you’re evaluating it seriously.

Best for: TypeScript teams building an app where both humans (via UI) and agents (via MCP/A2A/CLI) need to trigger the same underlying actions, who want that guarantee enforced by the framework rather than by developer discipline.

GitHub: https://github.com/BuilderIO/agent-native

Last updated: 2026-08-03

References & Sources #

• Agent-Native on GitHub
• Agent-Native documentation
• Agent-Native template gallery
• Model Context Protocol