{"slug": "how-and-why-to-build-agent-first-apps", "title": "How (and why) to build agent-first apps", "summary": "Builder.io's Agent-Native framework enables developers to build agent-first applications where any UI action is automatically available to AI agents, keeping the agent and UI in sync. The open-source framework provides a unified system of composable actions that power both front-end and agent tools, allowing agents to operate any UI element and enabling voice, chat, and MCP-based interactions out of the box.", "body_md": "# How (and why) to build agent-first apps\n\n[AI coding](/blog/topics/ai-coding)\n\nIn 2026, you shouldn't be building a single application that's not agent first. But what does that mean, and how do I do it? Let me show you.\n\nTo make things easy, I'm going to use the [Agent-Native](http://github.com/builderio/agent-native) framework as a starting point, copying the command from the homepage and running it in my terminal.\n\nOnce the starting point's created, we'll `cd`\n\ninto our app and use Claude, or whatever you prefer, to add our first prompt.\n\nTo make it a to-do app, I'll just say, \"Make this a to-do app.\"\n\nThis framework comes with a bunch of skills and instructions built in, so just asking any agent to do what you want or make what you want should give you a good starting point.\n\nNow that Claude is done, we have this.\n\nLooks like a to-do app, works like a to-do app.\n\nIt seems basic on the surface, but here's the important part: by default in this application, anything the UI can do, an agent can do.\n\nSo for instance, I can say \"add a to-do to make my demo.\" Plug in any model that you want, any keys that you want, and ask anything of the app you want.\n\nIf I update the UI, the agents are aware. And when I send commands to the agent, the changes reflect instantly in the UI. The agent and the UI are always in sync.\n\nAnything the UI can do, the agent can do, no matter what.\n\nAnd so that means if you want a completely agent-first experience, you can just use the chat. From the chat, you can have it bring UI to you.\n\nFor instance, if I say \"show me my to-dos\", it'll bring the full to-do UI right to me -inline in the chat, fully interactive.\n\nThe agent can operate anything. I can ask it to take me to the todos page, and the app can move from chat on the side to chat as the focus.\n\nYou can put `/mcp`\n\nat the end of any Agent-Native app URL and connect it to any agent.\n\nNow I can manage my tasks from Claude or ChatGPT, and say things like \"mark my demo to-do as done.\"\n\nI can also talk to my agent using GPT Realtime voice.\n\nHow can I help you?\n\nPlease delete my \"make my demo\" to-do.\n\nAll set. I deleted \"make my demo\" from your to-do list.\n\nJust have a conversation with your app.\n\nIn the case of using the Agent-Native framework, I got all these pieces for free.\n\nClaude didn't write all this from scratch. It assembled pieces from a toolkit.\n\nA toolkit is a bunch of these robust pieces like the chat UX, integrations, agent management, et cetera, and you build your app on top of that and integrate those pieces however you want.\n\nFor instance, if I now tell Claude, \"Let me edit each to-do in a Notion-style editor,\" what it'll do is borrow pieces from the toolkit.\n\nThe toolkit has things like a very rich Notion-style editor that you can import or eject and customize.\n\nEjection is a lot like how shadcn components work, where it copies the components to your code and you can edit any part.\n\nNow back in the app, I get buttons to open up a Notion-style editor. I can add sub items now - e.g. for apples, oranges, bread.\n\nI can add code snippets if I want, whatever you'd do in Notion you can now do here. It's effectively Notion's editor copy-pasted in here.\n\nUnder the hood, the framework builds everything in terms of actions. Actions are composable pieces that power your UI and the agent.\n\nIt is why, if I say something like \"add eggs to my get groceries detail list,\" the agent automatically can update anything.\n\nIt is a unified system for agent tools and front-end actions, so you only have to worry about one or the other.\n\nIf I build the front end and it has features, the agent can use every feature automatically.\n\nThat's what we mean by agent first. The unified abstraction makes things easy to build and debug with consistent behavior across the UIs and agents.\n\nAnd then when you only want to talk to it over agents or Telegram or Slack or Claude, that all just works out of the box.\n\nAnother use case I get for free is A2A (agents talking to other agents).\n\nI can say \"Hey, ask our analytics agent for some data\" and use that to create the to-do, like boosting our signups by 10% and what that number is.\n\nI generated this app inside a workspace. It's like a monorepo of multiple agents, or multiple agentic apps.\n\nBy default, they discover each other and can talk to each other. So if I want to grab data and generate a slide deck off of it, I can.\n\nIf I want to make a piece of content that references my to-do list, I can. You can make factories of knowledge work agents all within one monorepo, sharing code and skills and anything else, and each agent can have its own purpose-built UI too (like a google slides UI for slide viewing and editing, the Notion-style UI for content previewing and editing, etc)\n\nThe agent that comes out of the box here is also a full-featured agent, just like you'd use in Claude or Codex.\n\nSo we can add automations, integrations, create skills, add scheduled tasks.\n\nFor example, I can say, \"Check my Granola once an hour for follow-up items and add them as tasks.\" It'll prompt me with a button to connect Granola, and then, when done with that, submit my prompt.\n\nAfter a few seconds, my hourly job was created for me.\n\nThis runs in the cloud, so you can deploy it anywhere. For example, I'm using Netlify here.\n\nYou don't need any special agent servers or anything like that. Wherever you deploy any app, you can deploy one of these.\n\nAnd of course, the best part is this is all open source. It's MIT licensed. It's a foundation to build upon.\n\nSo if you've ever wanted your own version of Claude, Codex, whatever, but something you can build applications on top of to add value around and inside the agent - agentic apps are the future, in my opinion.\n\nI like to call them agents with faces.\n\nYou give up nothing from an agent, and you get everything from an app. And every moment, you can choose which you prefer, and interact with the agent from anywhere, from any agent, and to any agent.\n\nUnder the hood, these agentic apps are easy to build and maintain. Add as many apps as you want, or call them agents.\n\nI actually use those terms interchangeably now in this context. It could be a purely headless agent, something that looks just like an app and you only use remotely over MCP, or any combo in between like I showed you.\n\nAdd as many as you want in one monorepo. Add skills, instructions, components, and actions.\n\nActions is one of the most core abstractions here. All business logic is built in actions, and that's how we guarantee by default that everything the UI can do, the agent can do, and vice versa.\n\nThere's a core framework that keeps everything in sync and provides the foundation for it all.\n\nThere's also a toolkit of parts and pieces like the chat interface, agent management, real-time editing, settings and configuration, multi-tenancy and organization management, and tons of other pieces you might need, but built in a robust enterprise-grade way that powers a bunch of applications already online today that you can use.\n\nSo rather than having your coding agent reinvent the wheel each time, you can use the Agent-Native framework, install or eject the pieces you want, plug in any SQL database, use your own keys, and host it anywhere, because you own the whole software.\n\nThis is, in my opinion, the future of software.\n\nI like to call it clonable SaaS. Applications you can clone and customize, either from a full-feature template, and in building those, we create more pieces that you can use in your apps, or building apps from scratch.\n\nBut in the future, in my opinion, Salesforce will be a UI you can clone and customize and work with as an agent, or via an interface, or via another agent talking to other agents, or any way you want.\n\nIn the future, every application will talk to any other application, and in my opinion, we won't have a boundary or a difference between what is an app and what is an agent. Everything is both.\n\nAnd if you use frameworks and abstractions like this, you get all that stuff for free. So I can own my own software, I can own my own agents, I own my own IP, my own data.\n\nI'm in full control of the whole system, and humans and agents can edit any part anytime. The new abstraction, in my opinion, is a network of agents, call it an agent factory, but each agent has a UI.\n\nThe UI is critical for visualizing and customizing what the agent has done, as well as all those moments where its just easier to drag the text position of a slide, type the correction to a sentence, etc rather than waste time and tokens on an agent making precision edits.\n\nThe way we make our analytics agent so good is that our analytics team owns it.\n\nThey create the dashboards and the data dictionary and use those for their own data work, so when someone else in the org needs data, to make a slide deck or a blog post or whatever else, their app or agent just talks to the analytics agent and gets it.\n\nThe data's always high quality because it's the same corpus the data team uses every day, and the agent references the dashboards and examples they've already made.\n\nOur design team uses a design app. We have an image generation agent, so the team that makes image generation work great has an interface to upload images, create libraries, test out different generations, make sure they're on brand, see what others are doing, and tweak the instructions and the references.\n\nAnd it's all backed by code, so our engineers can customize every layer.\n\nThis is also why the agent abstraction works so well: you don't want one agent with every possible skill. You will bloat the context window. Too many tools, too many skills.\n\nInstead you make specialized agents.\n\nThe analytics agent has all the skills, tools, and data sources to be fantastic at analytics, so we know every time we ask it an analytics question, it does a great job.\n\nWhen my blog post needs analytics, I don't reach for one super agent. I have the one that's great at writing content talk to the one that's great at working with data, get an answer just like a human talks to another human, and then give me my draft.\n\nIf you want to try out the [Agent-Native framework](http://github.com/builderio/agent-native), source is [here](http://github.com/builderio/agent-native).\n\nOr, if you want to try an [Agent-Native app](https://www.agent-native.com/apps) for yourself, try out one [here](https://www.agent-native.com/apps), and even fork and customize them too.", "url": "https://wpnews.pro/news/how-and-why-to-build-agent-first-apps", "canonical_source": "https://www.builder.io/blog/agent-first-apps", "published_at": "2026-07-28 15:41:22.599855+00:00", "updated_at": "2026-07-28 15:41:24.803029+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools", "ai-products"], "entities": ["Builder.io", "Agent-Native", "Claude", "ChatGPT", "GPT Realtime", "Notion", "shadcn", "MCP"], "alternates": {"html": "https://wpnews.pro/news/how-and-why-to-build-agent-first-apps", "markdown": "https://wpnews.pro/news/how-and-why-to-build-agent-first-apps.md", "text": "https://wpnews.pro/news/how-and-why-to-build-agent-first-apps.txt", "jsonld": "https://wpnews.pro/news/how-and-why-to-build-agent-first-apps.jsonld"}}