How Should Agent-Native Software Be Designed?

Recently, more and more people are saying that future software should be designed “for agents.” Many think this simply means adding a chat dialog at the front of all software, where users give natural language commands and the software automatically completes tasks. But I do not think that is it.

The easiest place to misunderstand “building software for agents” is right here. Many interpret it as just adding another interaction method—as long as you replace buttons and forms with a chat entry point, you are agent-native. But the chat box is just the entry point, not the core. What really needs to change is how the software is organized internally.

The Difference

Traditional software assumes humans are the primary users. People look at pages, understand context, decide what to do next, and can manually fix things when processes get stuck. So software only needs to provide well-designed pages, buttons, forms, and menus, leaving most process understanding and usage to the users themselves.

But agents are different. Agents are not good at “reading pages and guessing processes,” nor should they rely heavily on implicit experience. They work better with clear objects, explicit actions, structured states, verifiable results, and well-defined permission boundaries. In other words, if software truly wants agents to become important users, it can no longer be designed around pages and processes alone—it must be designed around whether “tasks can be reliably executed.”

Take business travel as an example. This scenario is typical because it has almost all the characteristics suitable for agent involvement: long processes, many rules, approval requirements, budget constraints, and real bookings and cancellations. An employee completing a trip involves submitting a travel request, checking company policies on allowable tickets and hotel tiers, comparing times and prices, waiting for approval, proceeding with bookings after approval, and sometimes syncing itineraries with colleagues or adding them to calendars. On the surface, this seems like a “ticket booking” problem, but behind it lies an entire workflow.

How would traditional software design this? Usually by creating a whole set of pages: a menu for “travel requests,” another for “flight booking,” one for “hotel booking,” plus “approval records” and “expense management.” People with different permissions access different interfaces to complete their respective steps. The software provides these pages and teaches users what to do. But what comes first, what comes second, when to roll back, modify, or resubmit—all rely on user understanding. In other words, software provides a toolbox, while process comprehension comes from people.

This model worked in the past because humans were indeed the main executors. The problem is, if we want agents to take on more execution work, this design becomes unreliable. For agents, menu structure is not capability structure, and page entry points are not task entry points. What they need more are clearly defined actions: create travel request, check travel policy, search compliant transportation options, search budget-compliant hotels, generate itinerary proposals, submit for approval, make official bookings, modify bookings, cancel. Software should no longer be just a “collection of pages” but should gradually become a “collection of task capabilities.”

This is what I think many people have not truly figured out yet. Building software for agents requires reorganizing internal capability boundaries. Features previously scattered across multiple pages need to be abstracted into actions that agents can understand and call. These actions are not just button labels—they must have clear inputs, outputs, preconditions, and failure reasons. For example, “submit travel request” is not a vague phrase but should clearly require destination, time, travel purpose, and budget preference. “Check travel policy” should not just return yes or no but should tell the agent which item exceeds standards, why, and what allowable alternatives exist.

What Agent-Native Software Needs to Change

When software starts organizing this way, many things change. In the past, company travel policies might just be written in policy documents, understood through reading and experience. For instance: prioritize high-speed rail for Beijing-Shanghai unless there is a time conflict; hotels within a certain budget per night; business class only for certain levels; red-eye flights not recommended by default; trips over two days require additional approval. For employees, these rules just need to be “roughly known,” or if unclear, they can ask around because someone will always “cover” it. But for agents, fuzzy rules are a source of risk. It is not that they cannot make judgments—they cannot build systems on “roughly.” So agent-native software must make these rules explicit and structured. It must clearly tell agents what is allowed, what is restricted, which situations require exception requests, and which actions need human confirmation first.

Going further, truly agent-suitable software cannot just provide a bunch of low-level capabilities. Many software systems have APIs, but that does not mean they are agent-native. APIs might just program page actions, still requiring the caller to piece together dozens of steps. But what agents excel at is not blindly assembling granular actions—it is completing tasks at a higher semantic level. So a better travel system should not just provide “book flights” and “book hotels”—it should directly provide higher-level capabilities like “plan a compliant business trip.” Input: destination, dates, trip purpose, budget preference, and traveler info. Output: transportation options compliant with company policy, hotel options within budget, approval requirements, itinerary proposals, and currently missing information. This way, agents do not need to fumble through low-level processes but can complete tasks at a higher level, with better efficiency and stability.

However, just having actions and rules is not enough. There is another point often overlooked but actually crucial: state representation must be sufficiently clear. In traditional software, “in progress” often suffices. People see these three words, roughly know it is not finished, and will track it themselves. But agents cannot do this. They need to know exactly which step they are on, why it is stuck, what is allowed next, and what is not. If a travel request just shows “awaiting approval,” it is almost useless to an agent. But if the system tells it: current state is awaiting_manager_approval, reason is itinerary exceeds budget threshold requiring department head approval, next allowed actions are wait for approval, modify budget proposal, or submit exception request—then the agent knows what to do next and can be sufficiently stable.

There is another important point: do not confuse “automation” with “fully automatic execution.” Agent-native software does not mean all actions should be directly submitted by agents. On the contrary, truly mature agent software often emphasizes confirmation mechanisms. Because many actions carry inherent risks: payments, sending external messages, canceling existing arrangements, modifying official records, triggering approval workflows. A good system should naturally support layered actions like analyze, propose, commit. Agents can analyze first, generate candidate proposals, and prepare execution drafts, but still get human confirmation before actually booking flights and hotels. For example, the system first presents two compliant proposals: one cheaper but with earlier departure time; one more comfortable but slightly higher total cost. After user confirmation, it executes the actual booking. This mechanism does not diminish agent value—it creates conditions for agent adoption. Because what companies really worry about is not whether agents are smart enough, but whether they will execute automatically when they should not.

Future Software Requires New Division of Labor

So “building software for agents” is actually an entire restructuring of product architecture. Traditional software asks: how to make human interaction more efficient? Future software should ask more: how can the system package a task into a capability that agents can reliably complete? This corresponds to completely different design philosophies. The former centers on operation logic, the latter on task orchestration. The former assumes process comprehension lives in users heads, the latter requires systems to clearly express processes themselves. The former tolerates much fuzziness and experience, the latter must make objects, states, rules, and boundaries explicit.

This is also why many so-called agent products today feel “advanced-looking” but do not really change anything. Because they often just wrap a natural language interface around complex, fragmented, human-experience-dependent software surfaces without reconstructing the underlying layers. The result: seemingly smooth execution but actually fragile; impressive demos but constant failures in production. Fundamentally, the problem is not that models are not smart enough—it is that the software itself is not ready to be used by agents.

From a more practical perspective, I think what is truly worth doing is finding scenarios with long processes, clear rules, verifiable results, and clear risk boundaries, then reconstructing one core workflow. Future software will not completely eliminate humans. A more realistic picture is: people gradually shift from manual clicking, manual rule-checking, and manual process-stringing toward confirming goals, reviewing proposals, and handling exceptions. Meanwhile, agents execute most specific steps within rule boundaries. At that point, the criterion for good software becomes whether a task can be reliably completed within the system. I think this is the direction truly worth discussing for “software designed for agents.”