# When Do You Actually Need an AI Agent?

> Customer support, lead routing, REDAR, and incident diagnosis show the practical difference between software-defined workflows and AI agents.

> 💡 **TL;DR: Key Takeaways**
> - **Software chooses the sequence in a workflow; the model chooses it in an agent.** An agent can select the next step and tool as well as produce a response.
> - **Use a workflow when the path is known in advance.** Agentic freedom becomes useful when new information genuinely changes what the system should do next.
> - **That freedom carries an operating cost.** More discretion means more evaluation, security controls, debugging, and operational overhead.

Imagine a customer support team trying to resolve incoming requests faster. Customers write without an order number, combine several problems in one message, and use language that does not match the company's internal categories. Fixed rules struggle to interpret these messages, so the team decides that a language model may help.

That decision gives AI a job. It does not yet define the model's role in the system.

The model might read a message and recognize a refund request. Software then retrieves the order, checks the deadline and product conditions, and returns the relevant facts. The model drafts a response, and a support representative sends it to the customer.

The same system could be designed differently. After reading the message, the model could decide what information it needs next. It might inspect the order system, retrieve the refund policy, ask the customer for missing information, or hand the conversation to a support representative. Each result informs what it chooses to do next.

The first design is a workflow: software determines the sequence of steps. The second is an agent. I am not using *agent* as another word for chatbot. An AI agent can do more than produce a response. It can also choose the next step and the tool it needs to move the work forward.

This may sound like a technical naming distinction. In practice, it changes the system's cost, failure modes, and auditability.

## What a workflow gives you

When the refund process is known, software can apply the same sequence to every request. The model interprets the customer's irregular message and drafts the response. Software checks the deadline, enforces permissions, and verifies that the refund record was actually created.

The model still performs valuable work, but it does not control the process. Its entry point, the data it can see, and the destination of its output are defined in advance.

That choice matters in day-to-day operations. If a refund goes wrong, the team can more easily identify the failed step. The paths to test are known. The rest of the process can continue to follow the same rules even if the model changes.

[Anthropic's guide to building effective agents](https://www.anthropic.com/engineering/building-effective-agents){.dofollow target="_blank" rel="noopener"} draws a similar line. In a workflow, models operate along paths defined by software. In an agent, the system lets the model choose the steps and tools it needs while the work is running. The guide recommends starting with the simplest approach that works.

If the steps are already known, using an agent means asking the model to choose a sequence the software already understands. In return, the operation takes on more tests, traces, and failure scenarios.

## How the distinction appears in two real systems

At Vanity, roughly 100,000 leads a year had to reach the right sales representative. Country, language, shift, leave, capacity, and previous ownership all affected the assignment. The decision was complicated, but the rules were known. [The lead management system we built](/from-rules-to-decisions-the-real-time-sales-intelligence-platform-we-built-at-vanity){target="_blank" rel="noopener"} applied those rules and sent the result to the CRM. It was a workflow that did not need a language model.

[REDAR](/redar-ai-powered-summaries-for-kap-disclosures-and-open-sources){target="_blank" rel="noopener"} is a private financial dashboard we use to monitor KAP disclosures and selected open sources. Software parses sources with a regular structure. When the structure breaks or the text arrives in an irregular form, a language model helps extract fields and prepare a summary. Software still manages ingestion, selects the processing path, and delivers the result through the web interface and Telegram.

The first system contains no AI. In the second, a model performs an important step. Software still controls the sequence in both. Adding a language model does not turn a workflow into an agent by itself.

## When an agent earns its place

Some work cannot be mapped reliably in advance. Suppose a procurement team is searching for a new supplier. A system may begin with the existing supplier list. If it cannot find the required certification, it may need to inspect an official registry, verify the delivery region, or return to the user for missing price information. The next research step depends on what the previous one uncovered.

Diagnosing a software incident follows a similar pattern. You may begin by checking whether a service is running. The result determines whether to inspect logs, test the network connection, or review a recent configuration change. New evidence changes the path of the investigation.

[Microsoft Research's FLASH study](https://www.microsoft.com/en-us/research/uploads/prod/2024/10/FLASH_Paper.pdf){.dofollow target="_blank" rel="noopener"} examined this kind of problem across 250 real incidents. The agent selected its next diagnostic step from the results returned by its tools. A version that separately tracked completed steps and the current state outperformed the other approaches tested in the study.

The research covered five incident scenarios, and performance fell sharply in a scenario that required interpreting some tool outputs. It is not a general instruction to hand every open-ended task to an agent. It supports a narrower conclusion: when new evidence genuinely changes the path, letting a model choose the next step can be useful.

That discretion still needs boundaries. Which systems may the agent access? May it complete an action on its own? How will it know that the task succeeded, and when should it stop? Without clear answers, flexibility becomes an operational burden.

## One system can use both

The same customer support system can combine the two approaches. Software verifies the customer's identity, enforces transaction limits, and records the change. The model interprets the message. A bounded agent may investigate an open-ended problem with a restricted set of tools. For an action that is difficult to reverse, such as issuing a refund, software rules or human approval take control again.

You do not have to label the entire system a workflow or an agent. The useful question is how much discretion the model needs at each step.

When the steps are known, a workflow is the more predictable starting point. An agent becomes relevant when the next step cannot be chosen until new information arrives. The decision should rest on whether that discretion improves the outcome, not on whether an agent appears more advanced.

One earlier question still comes first: does the process need AI at all? [I examine that decision through three real systems in When Does Process Automation Actually Need AI?](/when-process-automation-actually-needs-ai).

You can find the other decisions about models, information, authority, and evaluation in the [guide to designing an AI system for your business](/designing-ai-systems-for-business).

---

Language: English
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/when-do-you-actually-need-an-ai-agent