Agent-Native: A TypeScript Framework for Pairing Autonomous Agents With Real UIs

Table of Contents

Why This Repo, Why Now

Checking github.com/trending today, the top repository is BuilderIO/agent-native, described by its maintainers as “an open-source TypeScript framework for building agents that pair autonomous work with a purpose-built UI.” Its central pitch: define each capability once as an action, and that same action is usable by an agent as a tool and by a UI as a normal function call — both paths share the same validation, permissions, and implementation.

The framing behind the trending spike is a real friction point teams building AI features run into: coding agents get rich environments — files, tests, previews, terminals — that make their work inspectable, while most “AI features” bolted onto SaaS products only get a text box. Agent-Native’s argument is that knowledge-work agents need the same kind of environment: a UI that shows what an agent can do and lets a person inspect, edit, approve, or share its output, rather than a chat box floating disconnected from the rest of the application. The project also ships several open-source reference apps (Clips, Design, Slides, Analytics, Calendar, Mail, Assets, Content, Plans) built on the same framework, which gives visitors something concrete to click through rather than just documentation. As always, a trending position reflects visibility and momentum, not a verdict on quality, security, or production-readiness — those are reviewed independently below.

What the Technology Actually Is

Per the repository’s own README and DEVELOPMENT.md, Agent-Native is a pnpm monorepo written in TypeScript, built around a core library (@agent-native/core) that provides a CLI, server plugins, agent tools, and a Vite plugin. The framework’s central concept is the action: a single defineAction call (backed by a zod schema for input validation) that is simultaneously exposed as:

• a tool the agent can call,
• a typed function the UI calls via a hook like useActionQuery,
• an HTTP endpoint, and
• an entry point reachable over MCP, A2A, and the CLI.

Documented architectural pieces from the README and workspace layout (DEVELOPMENT.md) include:

• packages/core — the framework itself: CLI, server plugins, agent-tool wiring, and the Vite build plugin.
• packages/dispatch — described as the “workspace control plane”: vault, integrations, destinations, scheduled jobs, and cross-app delegation.
• packages/code-agents-ui — reusable React UI for agent-facing surfaces (chat, approvals, etc.).
• packages/migrate — a “Migration Workbench” engine for moving existing apps onto Agent-Native with resumable, verifiable migration runs.
• packages/embedding, packages/pinpoint, packages/scheduling — embedding Agent-Native apps/pickers into other apps, visual feedback/annotation tooling, and scheduling primitives (availability, bookings).
• A PostgreSQL backend for production, with PGlite supported for local development on any Nitro-compatible host, per the README.

At a high level, the framework’s stated design goal is that the agent does not click through the UI like a human would; it calls the same action layer the UI calls, so “shared actions,” “shared data,” and “shared application state” (current page, selected record, active view) stay consistent between what a person sees and what the agent can act on.

Purpose and Use Cases

Per the README, Agent-Native’s primary purpose is giving teams a way to build agentic applications — products where an autonomous agent and a human-facing UI operate on the same underlying capabilities and data — without maintaining two separate implementations (one for the agent’s tool-calling and one for the UI).

Documented use cases and target users include:

• Product and platform teams building AI features who want the agent’s actions and the UI’s functions to be the exact same code path, rather than a chatbot wrapper around unrelated business logic.
• Teams building “delegate and review” workflows — per the README’s included Agent chat surface, letting people hand off work to an agent, ask questions, and review results inside the product itself.
• Teams that need agent orchestration primitives out of the box — documented features include authentication and permissions, skills and memory, scheduled/event-driven automations, and multi-agent “agent teams” that can delegate to specialist agents in the same workspace or across connected agents.
• Developers migrating an existing application to an agent-native architecture, via the migrate package’s documented Migration Workbench.
• Anyone evaluating the pattern hands-on, via the project’s shipped reference apps (Clips, Design, Slides, Analytics, Calendar, Mail, Assets, Content, Plans) that double as worked examples of the framework in a real app shape.

The project explicitly states developers “bring your LLM, SQL database, tools, and infrastructure” and that “everything you build stays yours” — positioning itself as an application framework rather than a hosted agent platform.

Installation

Per the project’s README and DEVELOPMENT.md.

Prerequisites (for contributing to / running the monorepo)

• Node.js >= 22 (v24+ recommended)
• pnpm >= 10 (corepack enable to use the version pinned in the templates)

Recommended: scaffold a new agent (documented quick start)

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

Then follow the getting started guide for the full walkthrough.

Alternative: clone and run the monorepo itself

git clone https://github.com/BuilderIO/agent-native.git
cd agent-native
pnpm install

The postinstall script automatically builds workspace packages other packages depend on (shared-app-config, toolkit, core, code-agents-ui, migrate, pinpoint, scheduling, embedding, dispatch), per DEVELOPMENT.md.

Minimal getting-started example

Documented in the README’s “shared action” example — create actions/hello.ts:

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

// One action powers every app surface: UI, agent, HTTP, MCP, A2A, and CLI.
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}!` };
  },
});

The agent receives hello as a tool, and a React component can call the same function via useActionQuery("hello", { name: "Alex" }).

Quick Verification

Based on the documented commands:

1. Scaffold check — npx --yes @agent-native/core@latest create my-agent --standalone --template chat should scaffold a runnable starter project.
2. Monorepo dev check — after pnpm install in a clone of the repository, pnpm run dev:all builds core first and then starts every template app in parallel on sequential ports, per DEVELOPMENT.md.
3. Single-package check — pnpm --filter mail dev or pnpm --filter calendar dev runs a specific reference template app to confirm the workspace is wired correctly.
4. Docs site check — pnpm --filter @agent-native/docs dev runs the documentation site locally.
5. Test suite — the root package.json exposes pnpm test (full workspace test run) and pnpm test:fast (excludes DB, integration, e2e, live, and perf suites) as documented workspace scripts.

Security Review

Verified from the repository itself:

• No SECURITY.md was found in the repository root or .github/ directory at the time of writing, so there is no documented private vulnerability-disclosure process for this project.
• The framework’s core package (@agent-native/core, packages/core/package.json) is licensed MIT, matching the license stated at the bottom of the root README. The repository root package.json (a private, unpublished monorepo manifest) separately lists "license": "ISC", which applies to the workspace tooling rather than the published packages.
• The project runs an extensive CI pipeline (.github/workflows/ci.yml) on every pull request targeting main, including a “change scope” job that conditionally runs lint, typecheck, fast tests, content checks, core integration tests, plan e2e, evals, privacy checks, build, and “trusted acceptance” jobs depending on what changed — a large, actively maintained workflow surface rather than a single smoke test.
• Dependency updates are automated via a dependabot.yml workflow present in .github/workflows/.
• The repository ships a very large number of GitHub Actions workflows (over 40 at the time of writing), covering CI, e2e suites per app (mail, design, calendar signup), desktop/mobile build checks, Netlify/Amplify preview deployments, and scheduled nightly test runs — indicating active, ongoing maintenance rather than a dormant project.
• No published GitHub Security Advisories were found against this repository at the time of writing; absence of advisories is not proof of absence of vulnerabilities.

Security considerations to weigh yourself (not verified vulnerabilities — documented factors relevant to this class of tool):

• Agent-Native explicitly wires agent tool-calling to the same actions that back your production UI and, per the README, a PostgreSQL backend for production data. Any action you define is reachable by both a human through the UI and an LLM-driven agent through the tool interface — the framework’s documented “Authentication and permissions” feature is the control point for who and what can invoke which actions, and should be reviewed carefully for any action that writes data or calls external systems.
• The framework exposes actions over HTTP, MCP, and A2A simultaneously by design; each of these is an additional network-reachable surface for the same underlying logic, so the auth/permission model needs to be enforced consistently across all of them, not just the UI path.
• The documented “Automations” feature runs agent work on schedules or events, and “Agent teams” allows delegation to other agents, including across connected agents — both increase the blast radius of a misconfigured or overly broad action compared to a single-agent, single-surface setup.
• This is a young, fast-moving monorepo with many interdependent packages (dispatch, migrate, embedding, pinpoint, scheduling, and more); review the specific packages you depend on rather than assuming maturity is uniform across the whole workspace.

Practical recommendations:

• Pin an exact @agent-native/core version (and lockfile) rather than always installing @latest, especially before using it in anything beyond a local prototype.
• Scope authentication and permissions tightly for every action that touches production data or triggers side effects, since the same action is reachable from both the UI and the agent tool-calling path.
• Review which actions are exposed over MCP/A2A/HTTP versus kept UI-only, and disable surfaces you don’t need.
• Test agent-triggered automations and multi-agent delegation in an isolated environment before connecting them to production data or external integrations.
• Watch the repository’s own security advisories and release notes, since no SECURITY.md currently documents a disclosure process for this project.

Should You Use It?

Strengths: a genuinely coherent architectural idea — one action definition serving the agent tool interface, the UI, HTTP, MCP, A2A, and the CLI — backed by a real, actively developed monorepo with extensive CI coverage across many reference applications; a documented PostgreSQL-for-production / PGlite-for-local-dev data story; and several shipped, open-source example apps that make the pattern concrete rather than purely conceptual.

Limitations: no SECURITY.md or documented vulnerability-disclosure process currently exists for the project; the workspace is large and fast-moving with many interdependent packages of presumably varying maturity; and because actions are reachable from multiple surfaces (UI, agent, HTTP, MCP, A2A) by design, getting the authentication/permission model right matters more here than in a framework with a single access path.

Good fit for: teams building internal or customer-facing tools where an agent and a human UI need to operate on identical business logic and data, teams evaluating “agent + UI” architectures who want a concrete open-source reference rather than starting from a blank slate, and developers who want agent actions exposed consistently over MCP/A2A alongside a normal web app.

Evaluate alternatives if: you need a framework with an established, documented security-disclosure process today, you want a narrowly scoped single-purpose agent library rather than a full application framework and monorepo, or your use case doesn’t need a shared UI/agent action layer at all (e.g., a pure backend agent with no user-facing surface).

Primary sources used: GitHub repository · README · DEVELOPMENT.md · core package.json · CI workflow · Official docs