In 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.
To make things easy, I'm going to use the Agent-Native framework as a starting point, copying the command from the homepage and running it in my terminal.
Once the starting point's created, we'll cd into our app and use Claude, or whatever you prefer, to add our first prompt.
To make it a to-do app, I'll just say, "Make this a to-do app."
This 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.
Now that Claude is done, we have this.
Looks like a to-do app, works like a to-do app.
It 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.
So 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.
If 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.
Anything the UI can do, the agent can do, no matter what.
And 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.
For 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.
The 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.
You can put /mcp at the end of any Agent-Native app URL and connect it to any agent.
Now I can manage my tasks from Claude or ChatGPT, and say things like "mark my demo to-do as done."
I can also talk to my agent using GPT Realtime voice.
How can I help you?
Please delete my "make my demo" to-do.
All set. I deleted "make my demo" from your to-do list.
Just have a conversation with your app.
In the case of using the Agent-Native framework, I got all these pieces for free.
Claude didn't write all this from scratch. It assembled pieces from a toolkit.
A 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.
For 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.
The toolkit has things like a very rich Notion-style editor that you can import or eject and customize.
Ejection is a lot like how shadcn components work, where it copies the components to your code and you can edit any part.
Now 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.
I 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.
Under the hood, the framework builds everything in terms of actions. Actions are composable pieces that power your UI and the agent.
It is why, if I say something like "add eggs to my get groceries detail list," the agent automatically can update anything.
It is a unified system for agent tools and front-end actions, so you only have to worry about one or the other.
If I build the front end and it has features, the agent can use every feature automatically.
That'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.
And 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.
Another use case I get for free is A2A (agents talking to other agents).
I 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.
I generated this app inside a workspace. It's like a monorepo of multiple agents, or multiple agentic apps.
By 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.
If 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)
The agent that comes out of the box here is also a full-featured agent, just like you'd use in Claude or Codex.
So we can add automations, integrations, create skills, add scheduled tasks.
For 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.
After a few seconds, my hourly job was created for me.
This runs in the cloud, so you can deploy it anywhere. For example, I'm using Netlify here.
You don't need any special agent servers or anything like that. Wherever you deploy any app, you can deploy one of these.
And of course, the best part is this is all open source. It's MIT licensed. It's a foundation to build upon.
So 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.
I like to call them agents with faces.
You 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.
Under the hood, these agentic apps are easy to build and maintain. Add as many apps as you want, or call them agents.
I 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.
Add as many as you want in one monorepo. Add skills, instructions, components, and actions.
Actions 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.
There's a core framework that keeps everything in sync and provides the foundation for it all.
There'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.
So 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.
This is, in my opinion, the future of software.
I 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.
But 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.
In 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.
And 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.
I'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.
The 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.
The way we make our analytics agent so good is that our analytics team owns it.
They 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.
The 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.
Our 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.
And it's all backed by code, so our engineers can customize every layer.
This 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.
Instead you make specialized agents.
The 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.
When 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.
If you want to try out the Agent-Native framework, source is here.
Or, if you want to try an Agent-Native app for yourself, try out one here, and even fork and customize them too.
