When not to use an AI agent

An AI agent is justified when a system must interpret changing context, choose among several permitted actions, and continue a task whose next step cannot be completely specified in advance. It is not justified merely because a workflow has more than one step. If the sequence and rules are known, ordinary application code is usually cheaper to test, easier to audit, and more predictable in production.

At Paul Titov & Co, we evaluate the job before the model. We ask what information changes the decision, which actions are allowed, what a wrong action costs, how success will be measured, and where a person must remain responsible. This separates an agent-shaped problem from an automation problem that needs a queue, a state machine, search, or a better interface.

Use deterministic software when the decision is already known

A rules engine is a better choice when inputs and outcomes can be enumerated: route an invoice by country and amount, retry a failed integration, apply an access policy, or move an order through documented states. These systems still need good engineering, but adding a language model creates uncertainty without adding useful judgement.

Search is often enough when the task is to locate an existing answer. A database query, full-text index, or filtered knowledge search can return the source directly. RAG becomes useful when the system must synthesise across sources or explain an answer in natural language, but retrieval does not automatically require an agent.

A queue and human review are better when mistakes are rare but expensive. The model can classify, extract, or prepare a recommendation while a person approves the consequential action. Calling the whole process autonomous does not improve the outcome.

An agent needs an action boundary

Before an agent receives tools, each tool needs a narrow contract: what it can read or change, which identity it uses, how arguments are validated, whether confirmation is required, and how the action is recorded. “Access to the CRM” is not a permission model. “Read these account fields” and “draft, but do not send, a reply” are permission boundaries.

The fallback is part of the feature. When context is missing, a tool fails, the model is uncertain, or the budget is exhausted, the product should know whether to ask a question, return a partial result, use a deterministic path, or send the task to a person. An agent without a defined stopping condition is an unbounded operational risk.

Start with the least autonomous useful version

The first production version should usually recommend before it acts. That creates real examples for evaluation and shows where users accept, correct, or ignore the output. Autonomy can expand after the team has evidence about accuracy, exceptional cases, latency, and cost.

Our rule is simple: use an agent only when adaptive choice is part of the value. Use ordinary software for known rules, retrieval for known information, and human approval for consequences the business is not ready to delegate.