Agent-Native: Stop Making Your Agent Click Through the UI

Agent-Native is a TypeScript framework from Builder.io for building applications where an AI agent and a human interface are peers rather than one wrapping the other.

It passed 4,900 GitHub stars in roughly six months. The package versions tell you how fast it is moving: @agent-native/core is already past 0.182, which is a lot of releases for half a year.

The whole framework rests on one idea, and it is a good one. You define a capability once. The agent gets it as a tool. Your React code calls the same function. So do HTTP, MCP, A2A and the CLI. One implementation, one schema, one set of permissions, six ways in.

An action is an ordinary TypeScript module with a zod schema and a run function:

import { defineAction } from "@agent-native/core/action";
import { z } from "zod";

export default defineAction({
  description: "Return a friendly greeting.",
  schema: z.object({
    name: z.string().default("world").describe("Name to greet"),
  }),
  http: { method: "GET" },
  run: async ({ name }) => {
    return { message: `Hello, ${name}!` };
  },
});

That file does six jobs. The agent receives hello as a callable tool. React calls it with useActionQuery("hello", { name: "Alex" }). It is simultaneously an HTTP endpoint, an MCP tool, an A2A endpoint and a CLI command.

Look at what the description fields are doing. They are not comments. description on the action becomes the tool description the model reads, and .describe() on each field becomes the parameter documentation. The prompt engineering for your tools lives in the same file as the implementation, so it cannot drift from it.

The zod schema is the load-bearing part. It produces the JSON Schema the model sees, it validates what the UI sends, and it validates what the agent sends, all from one declaration. If you are hand-writing tool definitions elsewhere, a JSON Schema generator will show you the shape this is producing for you.

One naming detail to plan for: the same action surfaces as a TypeScript function, an HTTP route, an MCP tool name and a CLI command, and those four worlds disagree about casing conventions. A case converter is a duller fix than it sounds but you will want it when you are being consistent across all six surfaces.

This sentence from the README is the thesis:

The agent does not click through the UI. It works through the same action layer as the UI.

It is worth sitting with, because the entire browser-automation category exists to do the opposite. Tools that drive a real browser teach an agent to find the button, click the button, wait for the page, read the result. That approach earns its place when you do not control the application, which is most of the web.

But when you do control the application, driving your own UI is a strange choice. You are making the agent operate a lossy, brittle, visual rendering of an API you wrote. Every layout change breaks it. Every loading state is a race. The agent burns tokens reading a DOM to recover data your server already had structured.

Agent-Native's position is that the interface was never the API. The UI is one consumer of the action layer and the agent is another, which means the agent gets the same validation, the same permissions and the same implementation, with none of the clicking.

The trade is scope. This only works for applications you build with it. It is a framework, not an integration, so it has nothing to say about the SaaS tools you do not control. The two approaches answer different questions, and the honest summary is: drive the browser for other people's software, share the action layer for your own.

Three similar-sounding ideas are circulating right now and they are genuinely different things. Worth separating, because the terms get used interchangeably and should not be.

Generative UI hands layout decisions to the model. Agent-Native does close to the reverse: a designer builds the interface, a developer builds the actions, and the agent is given the same capabilities rather than the ability to invent screens. If you want an interface that assembles itself per request, this is not that framework.

AG-UI and A2UI solve the transport problem of getting agent state to a browser. Agent-Native addresses a layer beneath that, namely what the agent and the UI are both calling in the first place. They are closer to complementary than competing.

Getting these three confused is easy and expensive, because they imply completely different amounts of design control.

Shared actions are the headline, but two quieter pieces are what make the result feel coherent rather than like two programs sharing a database.

Shared data. Work the agent does appears in the UI. Work you do in the UI is visible to the agent. There is no sync step and no separate agent-memory store that slowly diverges from the real records.

Shared application state. The agent receives relevant UI context: which page you are on, which record is selected, which view is active. This is the part that removes a whole category of stupid conversation. Without it, every request starts with re-establishing context you can both plainly see. With it, "summarise this" has a referent.

Anyone who has built a chat sidebar into an existing app has hit this. The chat knows nothing about what the user is looking at, so you end up hand-rolling a context payload, deciding what to include, and updating it every time the app grows a new screen. Agent-Native treats that as framework responsibility rather than something each app reinvents.

The framework ships the unglamorous infrastructure that usually eats the first month of an agentic app:

• Agent chat, so people can delegate work and review results in the same interface.
• Authentication and permissions, controlling who can see and change shared work. This is the one that matters most, because an agent with a tool layer and no permission model is a liability.
• Skills and memory, giving agents reusable expertise and persistent context.
• Automations, running agent work on schedules or events rather than only on request.
• Agent teams, delegating to specialist agents in the same workspace or across connected agents.
• PostgreSQL in production with PGlite for local development, on any Nitro-compatible host.

PGlite locally and Postgres in production is a good default. You get a real database in development without running a container, and no dialect surprises when you deploy.

The stated deal is "bring your LLM, SQL database, tools, and infrastructure. Everything you build stays yours." Worth noting that Builder.io is a commercial company, and frameworks from commercial companies sometimes grow a hosted path that becomes the easy one. Nothing here suggests that yet, and the architecture is portable by construction, but it is the thing to watch.

Because actions are exposed over HTTP as well, you will sometimes be poking at them with curl, where a URL encoder matters for query parameters and a JSON escaper saves time when you are embedding a payload in a shell command.

Most frameworks ship a counter and a todo list. Agent-Native ships nine open-source applications, all real enough to use:

This is the most useful thing in the repository and the reason to look even if you never adopt it. A framework's documentation tells you what the authors think the abstraction is for. Nine complete applications tell you whether the abstraction survives contact with real features like calendars, email threading and media handling.

They also double as starting points. "Fork the Mail app and change it" is a materially different proposition from "read the docs and build email from scratch".

One command:

npx --yes @agent-native/core@latest create my-agent --standalone --template chat

--standalone gives you a self-contained app rather than something wired into a larger workspace, and --template chat starts from the agent chat surface. Other templates and a full walkthrough are in the getting started guide at agent-native.com.

From there the loop is: write an action in actions/, and it is immediately available to the agent, to React through useActionQuery, and over HTTP, MCP, A2A and the CLI. There is no registration step, no separate tool manifest, and no second place to update when a signature changes. That last property is the one that pays off over months.

Worth a short, accurate note, because it is the kind of thing that gets reported badly in both directions.

The README has a License section that says MIT. The published packages agree: @agent-native/core, @agent-native/agentkit and @agent-native/toolkit each declare "license": "MIT" in their manifests. What is missing is a LICENSE file at the repository root, so GitHub's licence detection finds nothing and the repo page shows no licence badge.

In practice, if you install the packages you are on MIT terms and that is clear. The gap only matters if you are forking the whole repository or your employer's compliance process reads GitHub's detected licence field rather than the README, which plenty of them do.

It reads as an oversight rather than anything deliberate, and adding one file fixes it. Flagging it because "no licence detected" on a 4,900-star repo sets off scanners, and the answer is more boring than it looks.

A good fit if you are building a new application where an agent is a first-class participant rather than a chat box bolted to the side, you are already in TypeScript and React, and you want the permission model and the tool layer to be the same code.

A bad fit if you need an agent to operate software you do not control, which is browser automation's job, or if your stack is Python, or if you want an agent bolted onto a large existing app without restructuring how its capabilities are expressed.

Be aware of the age. The repository is about six months old and core is past version 0.182. That release count means active development and it also means the API is still moving. Pin your versions and read the changesets before upgrading.

The bet this framework makes is the interesting part, and it is worth stating plainly: applications built for agents will be structured differently from applications that had agents added to them. If that is right, the action layer belongs at the centre rather than being reverse-engineered out of a UI later. If it is wrong, you have still written a well-typed API with validation in one place, which is not a bad consolation prize.