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

Builder.io released Agent-Native, an MIT-licensed TypeScript framework that lets developers define an action once with defineAction() and automatically expose it as web UI, HTTP API, MCP tool, A2A endpoint, and CLI command. The framework, which has over 4,300 GitHub stars as of August 2, 2026, aims to eliminate duplication and drift between UI-facing and agent-facing APIs by using a single validated action across all surfaces.

Agent-Native: Define an Action Once, Ship It as UI, Agent, MCP, and CLI Agent-Native is Builder.io's MIT-licensed TypeScript framework where a single defineAction powers every app surface at once — web UI, HTTP API, MCP tool, A2A endpoint, and CLI command — instead of writing separate integration code for each. - ⭐ 4374 - TypeScript - MIT - Updated 2026-08-03 AI Agent Frameworks Compared: LangChain vs CrewAI vs AutoGen vs LlamaIndex vs LangGraph https://dibi8.com/resources/llm-frameworks/ai-agent-frameworks-comparison-2026/ • MCP Server Security: 10-Server Production Stack https://dibi8.com/resources/llm-frameworks/mcp-server-security-audit-2026-real-cases/ Plans template — from agent-native.com/templates/plan What Is Agent-Native? 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 https://github.com/BuilderIO/agent-native 🌐 Docs : agent-native.com https://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 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 what-ships-with-the-framework Beyond action routing, four pieces are documented as part of the core: — define work once, use it from every surface Actions https://agent-native.com/docs/actions — chat, tools, skills, memory, jobs, observability, and handoffs, shipped together rather than assembled from separate packages Agent runtime https://agent-native.com/docs/agent-surfaces — any Drizzle-ORM-supported SQL database, any Nitro-compatible host Backend agnostic https://agent-native.com/docs/database — reusable building blocks for collaboration, sharing, settings, teams, and observability Toolkits https://agent-native.com/docs/agent-native-toolkit Quick Start 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 example-templates Chat template — from agent-native.com/templates/chat | Template | What it demonstrates | |---|---| Clips | An Agent-Native Loom-style screen recording/sharing tool | Plans | Visual plan mode for coding agents | Design | An Agent-Native Figma-style collaborative design tool | Content | Agent-Native Notion/Obsidian-style content workspace | Analytics | Open-source alternative to Amplitude and FullStory | Chat | A minimal ChatGPT-style app for your own agent | The full gallery is at agent-native.com/apps https://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 agent-native-vs-bolting-an-agent-onto-an-existing-app | Aspect | Agent-Native | Typical “add an AI agent” retrofit | |---|---|---| UI and agent logic | Same action definition, both surfaces | Usually separate UI API + separate agent/tool API | MCP support | Built into the action-routing layer | Usually a hand-written adapter layer | A2A support | Same action-routing layer | Rare — often not supported at all | Agent runtime memory, skills, jobs | Ships as part of the framework | Usually assembled from separate packages | Risk of UI/agent drift | Low — one definition, one schema | Higher — two APIs to keep in sync by hand | Backend | Any Drizzle-supported SQL DB, any Nitro host | Framework-dependent | License | MIT | Varies | Use Cases use-cases 1. Apps Where the Agent Should Do Exactly What the UI Can Do 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 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 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 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-repositories | Repository | Purpose | |---|---| | Related Articles related-articles AI Agent Frameworks Compared: LangChain vs CrewAI vs AutoGen vs LlamaIndex vs LangGraph https://dibi8.com/resources/llm-frameworks/ai-agent-frameworks-comparison-2026/ — for comparing Agent-Native’s single-action-multi-surface model against orchestration-first frameworks MCP Server Security: 10-Server Production Stack https://dibi8.com/resources/llm-frameworks/mcp-server-security-audit-2026-real-cases/ — relevant once an Agent-Native app’s Actions are exposed as MCP tools in production Conclusion 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 https://github.com/BuilderIO/agent-native Last updated: 2026-08-03