BuilderIO released Agent-Native, an open-source framework that collapses a long-running tension in AI application design: the choice between a rich user interface and a capable autonomous agent.

The framework, published under an MIT license on June 18, treats the agent and the UI as “equal citizens of the same system.” Every action defined once — a reply to an email, a calendar booking, an analytics query — becomes available simultaneously from the UI, the agent, an HTTP endpoint, an MCP tool, an A2A handoff, and a CLI. The agent does not sit beside the app. It lives inside it.

This is not another chat-widget wrapper. Agent-Native ships a full application runtime: SQL-backed state, CRDT-based real-time multiplayer, per-user workspaces with persistent memory and skills, an agent runtime with jobs and observability, and a deploy target that runs on any Nitro-compatible host and any SQL database Drizzle supports. The templates that ship with it — Calendar, Content (an Obsidian-like MDX editor), Slides, Analytics, Clips — are complete, cloneable SaaS applications. Fork them, customize them with the agent, own the code.

The claim that matters: “Don’t choose between rich user interfaces and autonomous agents. Every Agent-Native app is both.”

The architecture of a unified system

The core primitive is defineAction. A developer writes a Zod-validated schema and a run function. That single definition generates a UI button, an agent tool call, an MCP tool, an A2A action, a REST endpoint, and a CLI command. The agent and the human operate on the same data, through the same contract.

This is a meaningful departure from the dominant pattern in 2025 and 2026, where agents are bolted onto existing applications via chat widgets or API wrappers. In those systems, the agent operates on a separate state plane — it calls tools, but the UI does not reflect its actions in real time, and the human cannot reach into the agent’s process and edit its work mid-stream.

Agent-Native flips that. The UI and the agent share one database and one state. CRDT merging means a human and an agent can edit the same document simultaneously, with live presence cursors and selection rings. The agent is a first-class peer editor, not a background process that returns a result.

The framework also introduces context awareness: the agent knows what the user is looking at. Select text in a document, hit Cmd+I, and tell the agent what to do. The agent operates on the current selection, not a vague prompt about the entire workspace. This is the difference between an agent that reads your mind and an agent that reads your screen.

Three shapes, one contract

Agent-Native defines three product shapes built on the same primitives. A headless shape exposes actions via code, CLI, HTTP, MCP, or A2A — useful for backend automation and CI/CD pipelines. A rich chat shape provides a standalone or embedded chat interface with native rendering for tables, charts, approvals, and setup flows. A whole-app shape delivers a full SaaS UI where chat can start central, move to the sidebar, and stay synced with app state.

The framework ships protocol support out of the box: A2A for agent-to-agent communication, MCP for tool exposure, MCP Apps for richer integrations, standard remote MCP OAuth, and connectors for OpenAI, AG-UI, Claude Agent SDK, and Vercel AI SDK chat runtimes. The documentation explicitly notes that ACP — the Agent Communication Protocol — is best understood as a coding-agent and editor interoperability protocol, not a general-purpose app-chat runtime. This is a useful distinction that many framework builders have elided.

The skill that upgrades coding agents

Agent-Native ships with a skill called visual-plan that installs two slash commands into Claude Code, Codex, Cursor, GitHub Copilot, and similar coding agents. /visual-plan opens a structured, reviewable plan document before the agent writes code: inline diagrams, UI wireframes and prototypes, file-by-file implementation maps, and annotations the user can comment on and approve. /visual-recap turns a PR or git diff into a visual before-and-after summary with schema, API, and file changes rendered as grounded blocks with a shareable review link.

This is a concrete improvement over the wall-of-text planning that most coding agents produce. The skill demonstrates what Agent-Native is good at: not just building apps, but building the tools that make agents more transparent and controllable.

The one-command install — npx @agent-native/core@latest skills add visual-plan — lowers the friction to zero. Try it, see if it changes how you review agent-generated code. If it does not, uninstall it. The framework does not demand commitment.

The economics of owned agents

The framework is MIT-licensed. The templates are cloneable SaaS applications. The database and hosting are bring-your-own. BuilderIO’s business model appears to be the same as it has been for Visual Copilot and its other open-source projects: sell a hosted version or enterprise features later, but give the code away now.

This matters because the agent framework market is consolidating fast. LangChain, CrewAI, AutoGPT, and a dozen others compete for developer mindshare. Most are abstractions over LLM calls and tool registries. Agent-Native is an application framework first and an agent framework second. It competes less with LangChain and more with Retool, Superblocks, and the low-code internal-tools market — but with an agent baked in from the start.

The framework’s documentation makes this explicit with a comparison table. SaaS tools offer polished but rigid UIs with bolted-on AI. Raw AI agents offer powerful capabilities with no UI. Internal tools offer full customization but high maintenance. Agent-Native claims to offer full UI, agent-first integration, agent-modifiable code, and full ownership. The claim is ambitious. The templates are real.

The open question

Agent-Native solves a real problem: the split between the agent’s world and the human’s world. Every developer who has built an agent-powered application has felt the friction of keeping state synchronized between a chat interface and a UI. The framework’s answer — one database, one state, one action surface — is elegant in theory and appears workable in practice, at least for the templates BuilderIO ships.

The open question is scale. Agent-Native runs on any SQL database and any Nitro-compatible host. That covers a lot of ground, but it does not cover the distributed, high-throughput, multi-region deployments that enterprise applications require. The framework’s real-time multiplayer uses CRDT merging, which works well for collaborative editing but introduces complexity for conflict resolution at scale. The agent runtime ships with observability and jobs, but the documentation does not describe how the system behaves under load, how it handles agent failures, or how it recovers from state corruption.

These are questions for production, not for a launch. BuilderIO has published a framework that makes a strong architectural argument. The next six months will show whether that argument holds at scale.