{"slug": "agent-native-define-an-action-once-ship-it-as-ui-agent-mcp-and-cli", "title": "Agent-Native: Define an Action Once, Ship It as UI, Agent, MCP, and CLI", "summary": "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.", "body_md": "# Agent-Native: Define an Action Once, Ship It as UI, Agent, MCP, and CLI\n\nAgent-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.\n\n- ⭐ 4374\n- TypeScript\n- MIT\n- Updated 2026-08-03\n\n[AI Agent Frameworks Compared: LangChain vs CrewAI vs AutoGen vs LlamaIndex vs LangGraph](https://dibi8.com/resources/llm-frameworks/ai-agent-frameworks-comparison-2026/) •\n[MCP Server Security: 10-Server Production Stack](https://dibi8.com/resources/llm-frameworks/mcp-server-security-audit-2026-real-cases/)\n\n*Plans template — from agent-native.com/templates/plan*\n\n## What Is Agent-Native? [#](#what-is-agent-native)\n\n**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.”**\n\n🔗 **GitHub**: [https://github.com/BuilderIO/agent-native](https://github.com/BuilderIO/agent-native)\n🌐 **Docs**: [agent-native.com](https://agent-native.com)\n\nMIT 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.\n\n## The Core Primitive: `defineAction()`\n\n[#](#the-core-primitive-defineaction)\n\n```\n// One action powers every app surface: UI, agent, HTTP, MCP, A2A, and CLI.\nexport default defineAction({\n  schema: z.object({\n    emailId: z.string(),\n    body: z.string(),\n  }),\n  run: async ({ emailId, body }) => {\n    await db.insert(replies).values({ emailId, body });\n  },\n});\n```\n\nDefine the work once — a Zod schema for inputs and a `run`\n\nfunction for the logic — and that single definition is automatically callable from:\n\n**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\n\nThe 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.\n\n## What Ships With the Framework [#](#what-ships-with-the-framework)\n\nBeyond action routing, four pieces are documented as part of the core:\n\n— 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)\n\n## Quick Start [#](#quick-start)\n\n```\nnpx @agent-native/core@latest create my-app\ncd my-app\npnpm install\npnpm dev\n```\n\nFlags skip the interactive prompt for common starting points:\n\n```\nnpx @agent-native/core@latest create my-app --template chat\nnpx @agent-native/core@latest create my-app --headless\nnpx @agent-native/core@latest create my-app --standalone\n```\n\nThe 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.\n\n## Example Templates [#](#example-templates)\n\n*Chat template — from agent-native.com/templates/chat*\n\n| Template | What it demonstrates |\n|---|---|\nClips | An Agent-Native Loom-style screen recording/sharing tool |\nPlans | Visual plan mode for coding agents |\nDesign | An Agent-Native Figma-style collaborative design tool |\nContent | Agent-Native Notion/Obsidian-style content workspace |\nAnalytics | Open-source alternative to Amplitude and FullStory |\nChat | A minimal ChatGPT-style app for your own agent |\n\nThe full gallery is at [agent-native.com/apps](https://agent-native.com/apps); each template is a real starting point via the `create`\n\nCLI, not just a screenshot.\n\n## Agent-Native vs. Bolting an Agent Onto an Existing App [#](#agent-native-vs-bolting-an-agent-onto-an-existing-app)\n\n| Aspect | Agent-Native | Typical “add an AI agent” retrofit |\n|---|---|---|\nUI and agent logic | Same action definition, both surfaces | Usually separate UI API + separate agent/tool API |\nMCP support | Built into the action-routing layer | Usually a hand-written adapter layer |\nA2A support | Same action-routing layer | Rare — often not supported at all |\nAgent runtime (memory, skills, jobs) | Ships as part of the framework | Usually assembled from separate packages |\nRisk of UI/agent drift | Low — one definition, one schema | Higher — two APIs to keep in sync by hand |\nBackend | Any Drizzle-supported SQL DB, any Nitro host | Framework-dependent |\nLicense | MIT | Varies |\n\n## Use Cases [#](#use-cases)\n\n### 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)\n\nIf 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.\n\n### 2. Exposing Internal Tools to Both Humans and Coding Agents [#](#2-exposing-internal-tools-to-both-humans-and-coding-agents)\n\nAn 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.\n\n### 3. Building on a Template Instead of From Scratch [#](#3-building-on-a-template-instead-of-from-scratch)\n\nThe `create`\n\nCLI’s template flags (`--template chat`\n\n, 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.\n\n### 4. Multi-Agent (A2A) Systems Without a Separate Protocol Adapter [#](#4-multi-agent-a2a-systems-without-a-separate-protocol-adapter)\n\nBecause 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.\n\n## Related Repositories [#](#related-repositories)\n\n| Repository | Purpose |\n|---|---|\n|\n\n## Related Articles [#](#related-articles)\n\n[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\n\n## Conclusion [#](#conclusion)\n\n**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()`\n\ndefinition — serving UI, HTTP, MCP, A2A, and CLI from the same schema and the same `run`\n\nfunction — 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.\n\n**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.\n\n**GitHub**: [https://github.com/BuilderIO/agent-native](https://github.com/BuilderIO/agent-native)\n\n*Last updated: 2026-08-03*", "url": "https://wpnews.pro/news/agent-native-define-an-action-once-ship-it-as-ui-agent-mcp-and-cli", "canonical_source": "https://dibi8.com/resources/llm-frameworks/agent-native-builderio-2026/", "published_at": "2026-08-02 15:35:00+00:00", "updated_at": "2026-08-02 17:06:45.579366+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-infrastructure"], "entities": ["Builder.io", "Agent-Native", "defineAction()", "MCP", "A2A", "Claude Code", "Cursor", "Drizzle-ORM"], "alternates": {"html": "https://wpnews.pro/news/agent-native-define-an-action-once-ship-it-as-ui-agent-mcp-and-cli", "markdown": "https://wpnews.pro/news/agent-native-define-an-action-once-ship-it-as-ui-agent-mcp-and-cli.md", "text": "https://wpnews.pro/news/agent-native-define-an-action-once-ship-it-as-ui-agent-mcp-and-cli.txt", "jsonld": "https://wpnews.pro/news/agent-native-define-an-action-once-ship-it-as-ui-agent-mcp-and-cli.jsonld"}}