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 • MCP Server Security: 10-Server Production Stack
Plans template — from agent-native.com/templates/plan
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:
— define work once, use it from every surfaceActions— chat, tools, skills, memory, jobs, observability, and handoffs, shipped together rather than assembled from separate packagesAgent runtime— any Drizzle-ORM-supported SQL database, any Nitro-compatible hostBackend agnostic— reusable building blocks for collaboration, sharing, settings, teams, and observabilityToolkits
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 # #
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; 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 # #
| 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 # #
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 # #
| Repository | Purpose |
|---|---|
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 frameworksMCP 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