{"slug": "why-are-we-still-building-apps-just-for-humans", "title": "Why are we still building apps just for humans?", "summary": "Builder.io's Agent-Native approach puts application capabilities at the center as reusable \"actions\" rather than treating the UI as the primary entry point, so the same validation, permissions and business rules apply whether a human, an AI agent, an HTTP client, MCP, A2A or a CLI invokes them. The company argues that exposing an API to an agent is insufficient, citing an expense-management example where an agent changed an already-approved expense because its path skipped the approval check the UI endpoint enforced. Builder.io contends agents also need application context, not just a list of callable tools, to resolve requests such as which expense report to update.", "body_md": "# Why are we still building apps just for humans?\n\nImagine asking your AI-powered expense management app to update the amount of an expense you submitted last week, and it does!\n\nThe problem is, the expense has already been approved and should be locked from further changes. The UI would never have allowed this because the endpoint it calls checks for approval, but the agent took a different route that missed that check.\n\nThis is a problem we need to think about as we start building applications that can be used by humans and AI agents alike. Along with building intuitive UIs, we need to make sure that these new users (AI agents) follow the same rules.\n\n## The UI-first application\n\nConsider an application. The UI is the obvious entry point: you interact with the frontend, it sends requests to the backend, and the backend handles the business logic and data.\n\nIn a typical application, the logic behind these operations lives in API routes, controllers, services, or functions that the frontend calls. And that’s fine when the UI is the primary caller, but agents may need to perform the same operation without going through the UI at all.\n\nNow we have a question that traditional UI-first architecture doesn’t answer very well: **How do we make sure every caller uses the same application logic and follows the same rules?**\n\n## One capability, multiple callers\n\nTake the same expense management app. A person might update an expense through the UI, while an agent could do the same after a request like \"Change my hotel expense from last week to $300.\" Later, an external integration might need to update expenses too.\n\nThe action is the same, but each caller may reach it through a different path:\n\n- the UI calls an HTTP endpoint\n- the agent uses a tool\n- the CLI runs a command\n- an integration uses another API contract\n\nEach path may define its own validations, permissions, error handling, etc. Over time, these implementations can drift apart, allowing one caller to perform an operation that another would have blocked.\n\n## The Agent-Native approach\n\n[Agent-Native](https://www.builder.io/blog/introducing-agent-native) starts from a different place. Instead of making the UI the main entry point, it puts the application capability at the center.\n\nIn Agent-Native, that capability is represented as [an action](https://www.agent-native.com/docs/actions-overview/?ref=pratham). That action defines the input, validation rules, and behavior of that capability.\n\nThat same action can then be exposed through the surfaces that need it: UI, agent, HTTP, MCP, A2A, and CLI.\n\nIn our expense management app, we could define an `update-expense` action once and let the UI, agent, or other surfaces call into it.\n\nThe surface can still behave differently. The UI might show a form, the agent might call a tool, and an HTTP client might send a request. The interface changes, but the application logic stays in one place.\n\n## Why not just give the agent your API?\n\nIt might be intuitive to think that the solution is simply to expose an API for the agent. But an API tells a caller how to invoke an operation. It doesn’t automatically guarantee that every caller follows the same validation, permissions, data scope, or business rules.\n\nTake our expense management example. Giving the agent an endpoint to update expenses is easy enough. But the application still needs to check whether the user has permission to edit that expense, whether it has already been approved, and whether the requested changes are allowed.\n\nThose rules shouldn't care whether a person or agent is calling.\n\n## Agents need application context, not just tools\n\n[Giving an agent access to actions](https://www.builder.io/blog/how-to-use-webmcp) is useful, but that’s only part of the picture. If an agent only gets a list of callable actions, it may lack the context the UI already has.\n\nSay you're looking at an expense report and ask the agent to \"Update the hotel expense in this report.\" Which report? Which hotel expense? The UI already knows which report you're viewing and which expense you've selected. But unless we pass this context to the agent, it has to figure things out on its own.\n\nThe agent needs to know what the user is working on and what they're allowed to do with it.\n\nIn Agent-Native, the UI [shares that context as application state](https://www.agent-native.com/docs/context-awareness/?ref=pratham), such as the current view and the selected record, so the agent knows which hotel expense you mean.\n\n## So what do we need the UI for?\n\n[Agent-native](https://www.builder.io/blog/agent-native-apps) doesn’t mean agent-only.\n\nA UI is still useful for things people are better at doing directly: comparing options, editing content, working with visual information, collaborating with others, etc.\n\nAn agent might prepare a set of changes, but the user may still want to inspect them in a table, edit one item, and approve the final result.\n\nSo, the UI still has an important role in an agent-native application. Instead of being the only way into the application, it becomes one of the surfaces built on top of the same underlying capabilities.\n\n## Start with actions\n\nYou don't have to expose every action through UI, HTTP, MCP, A2A, and CLI from day one.\n\nStart by defining the action: what it does, what inputs it accepts, who can call it, and what data it can access. Then make that action available through the surfaces that actually need it.\n\nBy default, that action is available to the UI and the agent, as well as through HTTP, MCP, A2A, and the CLI. The choice is which surfaces to turn off when access isn’t needed.\n\nThis lets us support multiple ways to interact with the application while keeping the underlying logic in one place.\n\n## So, what does it look like in code?\n\nHere's how we could define the `update-expense` action from our earlier example, in `actions/update-expense.ts`:\n\nThe description tells the agent what the action is for, the schema defines the inputs, and `run` handles the update and its permission checks. Both the UI and the agent can call this action, so the changes to approved expenses would be rejected in either case.\n\n## This is where Agent-Native helps\n\nYou can build this architecture yourself. With a conventional stack such as TanStack Start, Rails, or Next.js, you can centralize business logic and then separately add an agent tool, an HTTP route, an [MCP server](https://www.builder.io/blog/mcp-server), a CLI command, and so on. The architecture can work well, but you’re responsible for keeping those surfaces aligned.\n\nAgent-Native starts with the shared action itself. That action is meant to carry the application behavior, validation, permissions, and data access, and the framework can expose it to the UI, agent, HTTP, MCP, A2A, or CLI from that same source.\n\nAgent-Native treats the action as the application boundary, so teams can reuse or extend an existing action instead of creating another route or tool for the same behavior.\n\nAnd it's easy to [get started](https://www.agent-native.com/docs/?ref=pratham), or you can [browse the source on GitHub](https://github.com/BuilderIO/agent-native).", "url": "https://wpnews.pro/news/why-are-we-still-building-apps-just-for-humans", "canonical_source": "https://www.builder.io/blog/ai-agent-actions", "published_at": "2026-10-22 17:40:55.479112+00:00", "updated_at": "2026-10-22 17:40:58.001789+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "developer-tools"], "entities": ["Builder.io", "Agent-Native", "MCP", "A2A"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/why-are-we-still-building-apps-just-for-humans", "markdown": "https://wpnews.pro/news/why-are-we-still-building-apps-just-for-humans.md", "text": "https://wpnews.pro/news/why-are-we-still-building-apps-just-for-humans.txt", "jsonld": "https://wpnews.pro/news/why-are-we-still-building-apps-just-for-humans.jsonld"}}