Sometime in January, I started using AI more frequently than usual to make sense of the popular consensus that this new technology would take everyone’s job. I began with coding agents and side projects for personal use. The models could turn my rough ideas into functional applications with the right prompts, but the first output never matched my design expectations, no matter how explanatory I made the prompts. So I went looking for a system that would make models follow guidelines and meet my standards. I ended up learning a lot about agents and agents skills.
An agent for the agency
My first agent was built at Zero and One Solutions, my software agency, because we had a challenge with our SOP, every client inquiry required the same set of recurring documents. We needed an invoice, a product brief with clarifying questions for the customer, a proposal, and a client-handoff doc, all following the structure we already used internally. To automate this process and maintain my expected standard, I designed a five layer agent workflow with distinctive skills for each operation.
- Skill definition and activation: I defined what the skill was responsible for, when it should be applied, and how it should handle incoming client enquiries.
- Context ingestion and fact extraction: I set it up to read client briefs, extract relevant details, and separate actual requirements from assumptions, missing information, and ambiguities.
- Document-specific generation rules: I defined what each department needed from the brief and how that information should be structured for its documents, whether for sales, product, design, or engineering.
- Guardrails and validation: I added rules to make sure the skill followed our existing templates, didn’t make up requirements, prices, or timelines, flagged conflicting information, and asked clarifying questions when details were missing.
- Output and human review: I made sure it generated the relevant documents while flagging uncertain, sensitive, or approval dependent details for human review rather than making those decisions on its own.
Observing this process work efficiently validated the buzz around the technology.
Beyond documents
That experiment planted a seed of curiosity that I simply couldn’t shake. I started thinking about other fields like video editing and music production, mostly imagining how AI could take part in the creative process. Eventually I tweeted:
“playing w ai so much these days and thinking ai first principles for building may end up being agent native apps, as in prioritizing agent’s experience as a primary user when designing and making technical decisions.”
What’s happening underneath
The more I worked with models through my CLI, the more curious I became about how they carried out tasks. I could give an agent access to a local folder and watch it find a file, run OCR, parse the details, and populate an Excel sheet I had set up. How was a language model doing that?
The answer was the runtime. The model reasons and decides what needs to happen. The runtime translates those decisions into tool calls that touch the filesystem, start processes, call APIs, or invoke libraries, then feeds the results back so the model can keep reasoning.
It is essentially an interface to the machine’s capabilities. Humans use windows, menus, folders, and icons to work with an operating system. The runtime gives an agent the same reach by letting it express intended actions programmatically.
When applications become agent-accessible
Exploring tool calling, agent runtimes, MCP, and eventually WebMCP led me to question how web applications themselves could be exposed as accessible resources for AI agents
Imagine opening a travel app and saying: “Find me the cheapest direct flight from Lagos to London next Friday after 6pm and book it if it’s under ₦500,000.” Instead of clicking through date pickers and filters, the agent interprets the intent and calls the application’s own tools: search_flights(), get_flight_details(), create_booking(), make_payment(). You state the outcome, and the agent orchestrates the steps.
I don’t think the average person will build their own booking agent from scratch. More likely, agents become an application-layer building block: the product ships its own agent as an interaction layer over the software, built by the people who know it best.
What designing for agents looks like
The reality is that if agents are going to use our apps, they need their own definition of 'user experience.' Humans can navigate a messy UI through trial and error, but an agent will break. This is where WebMCP comes in: it acts as the translation layer that turns web apps into agent-friendly ecosystems. Looking at how WebMCP brings this to life, a few essential design principles become clear:
- Tools that describe themselves. Names, descriptions, and parameters should make it obvious what create_booking() does and when to use it. The description is the agent’s interface.
- Predictable, structured responses. Return data an agent can reason over, and error messages that say what went wrong and what to try next.
- Clear permission boundaries. Define what an agent may do on its own, and what requires the user’s approval.
- Confirmation before anything irreversible. A tool call like make_payment() should not be executed on its own. Checkpoints and human interference should belong wherever money, data, or commitments change hands.
- Visibility. The user should be able to see what the agent did and why.
None of this replaces designing for humans. It adds a second user whose experience needs the same care.
Rethinking software from an AI-first perspective
Good product design has never really been about screens. The core question has always been: “What should the user be able to accomplish?”
The difference is how that question gets answered. Up until now, the answer has always been an interface: dashboards, menus, filters, forms, and multi-step flows that let users translate their own intent into a result. If you wanted to book a flight, track an expense, or organize a project, software gave you the controls, but the effort of navigating the steps stayed with you. AI-first design shrinks the distance between what someone wants and the work required to get it.
That’s why a chatbot in the corner of every product misses the point. Take a payments product for example, a dashboard can show a business its transactions, but an AI-first version could help it reconcile payments, catch anomalies, and act on them, with the business approving anything consequential. That kind of product only works if the underlying actions are exposed as well-designed tools, which brings us back to the design principles above.
There is a real difference between taking an existing interface and asking “Where can we add AI?” and asking “If software can reason and act, how much manual translation can we remove for the user?” The second question opens up problems that were previously too tedious, complex, or expensive to solve.
It also raises the stakes on trust. Once software acts on user’s behalf instead of just showing them buttons, visibility and control become essential. That circles back to the last layer of my skills file: know when to bring a human into the loop.
Not every experience should be automated. Traditional interfaces will not go away, and there will always be workflows where people want to browse, compare, and decide for themselves.
What Comes Next
Picture a few years from now. You run a small bakery, and you tell your supplier’s ordering platform that a big catering order just came in for Friday. The agent inside it checks what you have in stock, works out how much flour, butter, and packaging you’ll need, and compares delivery slots against your production schedule. It places the order and lines up a courier for Thursday evening. It pauses at the one decision that needs you: a supplier is offering a cheaper batch of butter, but it arrives a day later than you’d like. You never filled in a purchase form or phoned around for quotes. Every product you use has an agent like this at its core, built by the people who know the business best.
In that world, the interface still matters, but it becomes the place where you check, adjust, and decide, while the agent does the work in between. The quality of a product will depend on how well its agent can act, and that depends on the groundwork: well-described tools, structured responses, clear permissions, and confirmation before anything irreversible. Products that skip this will have agents that guess, and users will notice quickly.
I don’t know how fast this arrives, or what the standards will end up being. But the direction seems clear enough to build toward. Software has always had one user, the person at the screen. Now it has a second one inside the product, doing the work, and the teams that design for it early will set the standard for everyone else.