One action can serve React, HTTP, MCP, A2A, and an agent
Agent-Native's best idea is simple: define a capability once, with its input schema, permission rules, HTTP details, and implementation. The AI receives that action as a tool, while React code calls the same operation through a hook. The framework can expose it through HTTP, MCP, A2A, and the command line too. That avoids the common failure where a chat agent and the visible interface use separate business logic and gradually disagree about validation or access.
Shared data and shared UI context complete the model. Work done by an agent appears in the application, while the agent can know the current page, selected record, or active view. The included surface covers chat, memory, schedules, authentication, agent teams, and background work. Fourteen named templates in the development guide cover products such as mail, calendars, content, analytics, slides, and design. This is much closer to an application framework than a thin model SDK.
What happened when we ran it
Our sandbox installed 2,631 pnpm packages in 174 seconds and used 3,322 MB on disk. Building the monorepo succeeded in 753 seconds. We measured commit 9e2b478 in an unprivileged Node 22 Debian container with 3 CPUs, 8 GB of memory, and no secrets. The checkout itself was 213.1 MB, with 18,993 files and about 3,580,615 lines of source. Those figures describe contributor setup, not the footprint of one generated application.
The test command did not finish before our 900-second cap. Its final lines showed several packages/core spec files passing, including the sharing dialog, harness runner, workspace file store, API path, and HTTP response telemetry. The tail also contained an expected retry-exhaustion log and a missing i18next-instance warning. Neither message establishes what kept the command running. A timed-out suite is unresolved, even when its last visible tests are green.
Local PGlite becomes PostgreSQL and provider secrets in production
Node 22 and pnpm 10 are the documented minimums for repository development, with Node 24 recommended. The starter command can generate a standalone chat app, and local development falls back to PGlite when DATABASE_URL is absent. Production takes a PostgreSQL database. Common environment variables also cover the authentication secret and URL, an A2A secret, and the provider key used by the chosen agent engine. The README's bring-your-own-infrastructure line is literal.
Authentication, shared records, scheduled jobs, and external agents all increase the cost of a bad boundary. The development guide describes guard scripts for cross-tenant data leaks, credential leaks, unsafe production database pushes, and unscoped ownership queries. That is good evidence that the maintainers know where failures occur. It is also a map of what adopters must understand. The framework supplies mechanisms, but each action still needs correct authorization, idempotency, secret scope, and audit behavior.
Forty-five CI workflows do not turn a 900-second timeout into a pass
Our scan found 45 CI workflow files, no Dockerfile, no top-level tests directory, and a pnpm workspace layout. Tests are colocated with source, as the log tail confirms. The development guide offers several concurrency variables because each workspace runner can otherwise size itself from the whole host and oversubscribe the CPU when jobs run together. That warning matters on a 3-CPU container like ours and on shared CI runners.
The repository build took 753 seconds after a successful 174-second install. Its postinstall phase builds packages needed by other workspaces, and the root build covers packages plus templates. A small adopter should assess the generated app separately before assuming it inherits all 3,322 MB. A contributor, however, really does own this monorepo, its desktop and mobile apps, documentation, templates, migration tools, scheduling package, control plane, and guard system.
Open reports cover triple execution and broken MCP OAuth routing
Issue 4865 reports a confirmed turn on core 0.178.1 executing the same A2A delegation 3 times after a client-side exception. The report says the same turn_id produced three completed run rows, so repeated work could duplicate external calls, generated assets, or cost. That is a serious fit problem for actions with consequences. Until the behavior is fixed and verified on your chosen version, make write actions idempotent and reconcile provider calls against your own operation identifier.
Issue 4866 concerns path-mounted workspaces. It reports that OAuth discovery for spoke-app MCP servers is routed to Dispatch, causing an invalid_request when a client connects to an individual app. The described workaround uses the Dispatch connector or a static token on clients that accept one. Teams planning separate MCP connectors for several apps on one host should reproduce that exact route before adoption. Neither issue proves every deployment fails, but both are specific current production reports.
A six-month-old 0.1.x framework is moving quickly
BuilderIO created the repository on March 12, 2026. GitHub recorded a push on September 12, 2026, 4,737 stars, and 95 combined open issues and pull requests. Release v0.1.258 arrived on September 10 and is described as a stable desktop-app release, with installers for several operating systems. The current activity is clear. So is the early version line, and a desktop release label should not be read as a stability promise for every server and workspace interface.
Agent-Native earns a trial when the product itself is an agent workspace and visible, editable output is central. Its shared-action design is more coherent than bolting a chat box onto unrelated APIs. The price is a very large contributor environment, a build measured in minutes, and a full test command that exceeded 15 minutes on our box. Start with one generated app, test destructive actions for replay, and prove the intended MCP and authentication topology before adopting the wider suite.