When not to use agents

I think a lot of software engineers still get something deeply wrong with agentic systems: they should not replace traditional deterministic software.

What I mean is that new and exciting agentic approaches to software should not replace traditional methods. Instead, they should enable us to build new types of software.

For example, let’s say you’re building a hotel booking system. You’d go through all the basics: database models, views, forms, and UI. The works.

At its most basic, the interaction model would kind of look like this.

In the agentic world we now live in, I’ve seen software engineers propose a different architecture. They get a model and give it low-level tools like update_customer_information, reserve_room, send_transactional_email, etc., along with a system prompt explaining how the booking system should work. Then they expose a chat interface to the customer.

In the chat, a customer might say, “Find me a room for two nights under 300 USD.” The LLM will then try its best to figure out the right course of action according to its system prompt and the tools it has at its disposal. It will try to determine the dates and budget, then choose the best room based on its own judgment.

If it follows the system prompt closely, it may be able to do all this successfully. However, it’s far from guaranteed, and non-deterministic behavior is usually not what you want when building production systems.

Maybe someday models will get so good, so well aligned, that we can just give them bare tools, a system prompt and get 100% reliability. But that day is not today.

So what can we do instead? Here I propose two options.

Option one: Just don’t use agents.

Sometimes the tech industry is guilty of doing something just because everyone else is doing it, regardless of whether or not it’s appropriate. For the past year, I’ve gotten the sense that a lot of people are trying to integrate agentic approaches into their products, when there’s clearly no need to do so.

Don’t get me wrong. Sometimes, agentic is the right choice. But just as often, it isn’t.

Agentic architecture really shines when neither the problem nor the solution is clearly defined in advance.

Coding is a good example of this. There is no one-size-fits-all deterministic approach to writing software that writes software. Before LLMs, the best we could manage was autocomplete within IDEs.

On the flip side though, agentic architecture is terrible if you need a system that works the same way every time, like what most software actually needs to do. If that’s your product, you’re better off building with a traditional, non-agentic approach.

But I really want to build using agents! I hear you cry. In that case, the second approach might be more interesting.

Option two: Good AX (Agent Experience)

The main idea is to be smart about what tools to give to your agent. Instead of low-level tools like those in the example above, give agents tools that move business logic out of the LLM’s purview and into the tool layer.

I think it helps if you frame the problem like you’re building software that will be used by human operators. Going back to our booking system, if we want humans to be able to find and book rooms effectively, we need to design and build software with good UX.

The same is true for agents. The key to having a successful agentic system is good agent experience, or AX.

Instead of telling the agent to coordinate every step manually, give it a find_rooms tool. The tool could accept the guest’s information, dates, budget range, and other preferences. Then give it another tool called create_booking that accepts the guest’s information, chosen room, and dates, then returns a payment link.

Behind those tools, the booking system can make sure the offer hasn’t expired, lock the room inventory, calculate the authoritative price and taxes, prevent duplicate bookings and charges, authorize the payment, save the reservation atomically, and queue the confirmation email only after the transaction commits. If any step fails, the system can roll back the operation or return a defined failure.

Notice that this is pretty much what we’ve already been doing with traditional software, except now, our “user” is an AI agent.

In this model, the agent’s job becomes limited to understanding the customer’s request, collecting information, asking for confirmation, and explaining the result. The decisions about transaction order and preserving the system’s business rules stay deterministic behind the tool calls.

If built well, I think a system like this could potentially be more user-friendly than the UIs we have today. I know I’m not alone when I say I’ve spent hours upon hours scouring Airbnb for the perfect place to stay.

Know when to go agentic

The bottom line is, agentic isn’t a one-size-fits-all solution. In fact, it often isn’t appropriate. If you do decide to use it, don’t assume that it will behave. Instead, design good AX to maximize your chances.