Agent-Native is an open-source TypeScript framework that allows an interface and its AI agent to share the same functions and data.
It solves a practical problem when adding agents to an application: keeping their tools aligned with what the product does. If changing a meeting date works one way in the chat and another way in the calendar, you have two behaviors to maintain.
Builder.io’s proposal brings those operations together in a shared actions layer. The interface and the agent become two ways of working with the same application.
What is Agent-Native?
Agent-Native is a framework for building applications with an integrated agent and a visual interface where people can review and edit their work.
The repository includes starting points for calendars, email, presentations, analytics, and content. The idea connecting them is continuity: you can work from the interface, delegate a task to the agent, and review the result in the same environment.
Think of an editorial calendar. You select three drafts and ask: “Move them to next week, keeping the order.”
An application built with this approach could pass the draft IDs to the agent, allow it to invoke the scheduling action, and display the new dates in the calendar. It’s an illustrative example, not a test conducted for this article.
The framework provides the structure. You implement the scheduling rules and decide what changes need approval.
How does Agent-Native work?
It works through shared actions: you define an operation with its input schema and implementation, and invoke it from the interfaces the framework supports.
The official actions guide begins with this example:
// actions/hello.ts
import { defineAction } from "@agent-native/core/action";
import { z } from "zod";
export default defineAction({
description: "Say hello from the local agent.",
schema: z.object({
name: z.string().default("world"),
}),
http: { method: "GET" },
readOnly: true,
run: async ({ name }) => {
return { message: `Hello, ${name}!` };
},
});
The greeting is deliberately simple. What matters is the contract: a description the agent can use, structured inputs, and a single implementation.
The framework allows you to invoke actions from the interface, agent tools, HTTP, MCP, and the command line, based on the exposure permissions you define. These paths share validation and access controls. The agent uses tool calls to request operations.
In a real application, the action could update a reservation or save an edited slide. The development advantage is having a single place to maintain the behavior of that operation.
How does the agent know what you’ve selected?
The application provides the agent with relevant navigation and selection state.
This requires integration work. Your interface registers useful context, like the current view and IDs of selected items; then the agent can retrieve the corresponding data. The context awareness guide explains how to connect those pieces.
This way a request like “summarize this” can be helpful. The developer establishes what “this” refers to.
Data is also shared. The interface and the agent access the same PostgreSQL tables through the actions layer. Synchronization reflects changes in the interface: the result can appear as an updated record, ready for you to review and continue editing.
How do you install Agent-Native?
The documented starting point is creating a standalone application from the Chat template.
At the time of preparing this note, September 20, 2026, the getting started guide requires Node.js 22.22 or later, pnpm, and a connection to an LLM. These are its commands:
npx --yes @agent-native/core@latest create my-app --standalone --template chat
cd my-app
corepack enable
pnpm install
pnpm dev
```The template includes a browser interface, authentication, persistent conversations, application context, and a sample action.
The guide allows you to connect the agent through Builder.io, use compatible provider keys, or fall back to a local model with Ollama.
These instructions come from the documentation. We have not run the generated application or measured its performance for this article.
## Is Agent-Native free?
The framework is licensed under MIT, but that license doesn't eliminate inference or hosting costs.
Your application's cost will depend on the model you choose and the infrastructure you use. The ability to connect a local model is a deployment option; it also requires resources to run it.
## How do you control the permissions of an AI agent?
You must define what actions the agent can invoke, who is authorized to execute them, and which ones need human approval.
The distinction matters: a valid input doesn't mean the requested operation is appropriate.
According to the [authorization documentation](https://www.agent-native.com/docs/actions-access-control/), consulted on September 20, 2026, actions are available to the agent by default and human approval is disabled by default. You can require approval for calls with consequences and add authorization controls that apply across different execution paths.
Exposure to public agents is a separate and explicit decision. The fact that an agent can invoke an action doesn't automatically make it an anonymous public endpoint.
In the editorial calendar, viewing publication dates and modifying them may require different permissions. Sharing the implementation makes it easier to centralize those rules; you still need to define them.
## When should you use Agent-Native?
You should evaluate it when your product needs operations executed by an agent and an interface where people can review and continue the work.
I'd start with a small application and a useful operation available both ways. Verify that manual changes reach the agent, that its changes appear in the interface, and that permissions are respected in both cases.
It also means adopting an infrastructure structure. The documented data layer uses PostgreSQL and Drizzle. PGlite works for local development; shared deployments need persistent PostgreSQL. As of September 20, 2026, provisioning of managed databases by Builder.io is still listed as a planned feature, not yet available. The [database guide](https://www.agent-native.com/docs/server-database/) details these conditions.
If you already have a product, the question is how its operations and authorization rules fit into that structure.
In our [analysis of Project Solara](https://www.yodev.dev/t/microsoft-cree-que-las-aplicaciones-estan-muriendo-y-project-solara-nos-muestra-que-viene-despues/3128) we explored how agents could change applications. Agent-Native offers a concrete architecture to examine: people and agents working through shared functions, with an interface that keeps results visible.
That makes it a useful candidate for a scoped prototype. Adopting it in production requires testing the flows, possible failures, and deployment conditions relevant to your application.
https://github.com/BuilderIO/agent-native