# Share React dashboard actions with agents

> Builder.io’s Agent-Native beta puts an agent beside a React UI, with shared actions, data, and app state. Here is how to evaluate the pattern.
> By Dave · 2026-10-15
> Source: https://otf-kit.dev/blog/builder-agent-native-react-dashboard

## A dashboard can give an agent more than a chat box

A SaaS dashboard usually gives a person a list, filters, forms, and buttons. Adding an agent often means adding a chat panel beside that interface. The panel can answer questions, but the product still has two ways to act: the human uses the application, while the agent may be handed a separate collection of tools or a browser to click through.

Builder.io’s Agent-Native beta proposes a different shape for this problem. It is an open-source TypeScript framework for agent applications, and Builder says the app and agent share actions, data, and application state. A capability can be exposed across the UI, agent, HTTP API, CLI, MCP, and A2A surfaces. That makes the launch relevant to teams building a React SaaS dashboard: it gives them a concrete architecture to evaluate when they want an agent to act on the same records and workflow a user sees.

The important question is not whether an agent can click a dashboard. It is whether the application has a small, deliberate set of operations that both the UI and the agent can call, with the same validation and permission checks.

## What “shared actions” changes

Suppose a support dashboard has a case list. A user opens a case, changes its priority, and assigns it to a teammate. A separate agent integration might expose a tool called `update_case`, while the React screen has its own form handler. If those paths have different rules, the same request can behave differently depending on who initiated it. A new validation rule may be applied in the UI and forgotten in the agent tool, or the agent may write fields the screen never allows a person to change.

The Agent-Native model described by Builder puts the capability behind one action implementation. The agent calls that action as a tool; the UI calls it from application code. The launch says both paths go through the same validation, permissions, and implementation. In principle, that gives a team one place to reason about the operation instead of maintaining parallel behavior.

“One action” does not mean “one unrestricted endpoint.” A well-designed action still needs a narrow input schema, identity, authorization, tenant scope, and an explicit list of fields it can change. For example, an assignment action might accept a case ID and a teammate ID, then check that the caller belongs to the workspace and that the teammate is eligible. It should not accept a raw SQL string or a client-supplied workspace ID as proof of access. The server must derive or verify the caller’s authority.

This matters most for operations with consequences: changing account settings, issuing a refund, publishing content, or closing a customer case. A shared action can reduce duplicated logic, but it cannot decide which actions should require confirmation, which roles can perform them, or what should be logged. Those remain product and security decisions.

![Byte and Nova direct a UI action and an agent request through one shared approval checkpoint before a dashboard record changes.](https://cdn.otf-kit.dev/blog/builder-agent-native-react-dashboard/inbody1-20261015a.webp)

*Conceptual view of two callers reaching the same validation and permission boundary before a shared action changes data.*

## Shared data and selected UI state provide context

The second part of the proposal is shared data. Builder says work performed by the agent appears in the UI, and changes made in the UI are available to the agent. That avoids building a separate “agent memory” copy of a record just to keep a chat conversation informed. The source of truth still needs normal database constraints, transaction handling, and conflict rules; sharing the same data model does not remove those responsibilities.

The third part is application state. Builder’s launch gives examples such as the current page, selected record, or active view. That can make a short instruction like “summarize this” refer to the record already open on screen. Without that context, the agent may need to ask the user to paste an ID or repeat which item they mean.

Treat UI context as a convenience, not authorization. A selected row tells the agent what the user is discussing; it does not prove that the user may read or modify that row. The server action should re-check access on every call, including calls made after the agent has been idle or the page selection has changed.

![Luna selects a dashboard record that remains visible while Nova receives its context; a separate locked control represents authorization.](https://cdn.otf-kit.dev/blog/builder-agent-native-react-dashboard/inbody2-20261015a.webp)

*Conceptual illustration of selected-record context reaching an agent while authorization remains a separate check.*

## A practical evaluation path for a React SaaS team

Start with one low-risk workflow that already has a clear UI operation. A good pilot is “summarize the selected case and propose a priority change,” where the user remains the final approver. Avoid beginning with bulk deletion, financial actions, or a wide-open workspace assistant. The pilot should test the shared-action idea, not maximize autonomy.

First, write down the operation as a contract. Specify the fields it reads, the fields it may change, who can call it, which records are in scope, and what a successful result looks like. Add invalid and unauthorized cases before connecting the agent. This gives the UI and agent the same behavior to exercise.

Next, expose the operation to the existing React screen and confirm that the normal user path still works. Then connect the agent to that same operation. Ask it to perform a task using the selected record, and inspect the exact structured inputs it submits. Test missing context, stale selection, malformed inputs, a user from another tenant, a user without the required role, and a retry after a timeout. A fluent chat answer is not evidence that the action boundary is correct.

Keep the first agent response in a proposal or preview state. Show the user the target record and proposed change, then require an explicit confirmation before committing a consequential update. Record the actor, selected workspace, action name, inputs after validation, result, and whether the user approved it. Those controls make it possible to investigate surprising behavior later.

Finally, compare maintenance costs rather than only demo speed. Are the UI and agent truly invoking the same implementation? Do tests cover both entry points? Can a developer trace which rule rejected an action? Can the team revoke an agent capability without breaking the human interface? If the answers are unclear, shared abstractions may only hide two separate systems behind one label.

## What to verify before adopting a beta framework

Builder announced Agent-Native as a beta on October 14, 2026. Treat the framework as something to evaluate, not a guarantee that every production concern is solved. Read the current documentation, inspect the repository and examples, and verify the parts your product depends on: framework and runtime compatibility, data migrations, session and tenant boundaries, deployment behavior, logging, upgrades, and support for your chosen model and database.

The launch describes integrations across several surfaces, including MCP and A2A. Each additional surface expands the places from which an operation can be invoked. Make a capability inventory and enable only what the product needs. An action intended for the in-app agent should not automatically become available to every external client merely because the framework can expose it there.

Also separate model quality from application safety. A model may choose the wrong action or produce unsuitable arguments. Schema validation catches malformed inputs; authorization checks prevent callers from exceeding their access; business rules prevent invalid transitions; and confirmation gates put a person in control of sensitive changes. No single layer replaces the others.

## Where an OTF kit fits

If your team wants a starting point for the surrounding SaaS interface, the [SaaS Dashboard kit](https://otf-kit.dev/templates/saas-dashboard) is an optional editable app shell priced at $99. It is not an Agent-Native integration and does not include this framework setup. Treat it as a separate UI foundation to inspect, not as a shortcut that removes the integration work described above. Check the live demo and current terms before deciding whether its structure fits your app.

For a related but different problem, see [how to make a website readable to AI agents](https://otf-kit.dev/blog/make-your-website-agent-readable). That article is about helping an agent understand a website; this one is about sharing application actions and state between an agent and a React product UI.

## Sources

- [Introducing Agent-Native Beta: The Framework for Agentic Apps](https://www.builder.io/blog/introducing-agent-native) — Builder.io, October 14, 2026. Launch scope, beta status, shared actions/data/state, supported surfaces, and local development claims were checked against the vendor announcement.