Agents and workflows: decide whether you need an agent first

"Agent" has been one of the hottest words of the past couple of years. It can seem that everything has to be an agent to count as advanced.

Before you build anything, answer one question: does your task really need an agent? This lesson first draws a clear line between agents and workflows, then uses an experiment to see how much their costs differ, and finally gives a checklist for deciding.

The difference

Recall how RepoBot v2 answers a question: rewrite the question, retrieve documents, hand the documents and the question to the model to answer. Those three steps are hard-coded in your program, in a fixed order, the same every time. The model is only responsible for the specific content of two of them: what words to rewrite into, and what to answer. This is called a workflow.

An agent is different: you give it only a goal and a set of tools, and the model decides what to do next. It might search first, see the results are off, and search again with other words; it might read one file, decide that's not enough, and read another; or it might decide it has enough information and answer straight away. The number and order of steps aren't known in advance.

工作流：                          智能体：
  改写问题（固定）                   ┌─▶ 模型决定：下一步做什么？
     ▼                             │       │
  检索文档（固定）                   │   ┌───┴───┬────────┬────────┐
     ▼                             │  搜索   读文件   列目录    回答 ──▶ 结束
  回答（固定）                       │   │       │        │
                                   └───┴───────┴────────┘

There's no sharp line between the two. A workflow in which one step lets the model decide "should I retrieve?" is already a bit agent-like. The more useful question is: who holds control. The more control is handed to the model, the more flexible the system and the harder it is to predict.

Experiment: the same questions, two ways

Using Module 04's RAG workflow (rewrite, hybrid search, cited answer) and the agent we'll write in the next lesson (which decides for itself when to use grep_docs, read_doc and list_docs to search the docs), answer the same three questions. Code in code/05-agents/workflow_vs_agent.py; my run (the middle part is the agent's trace, step by step):

问：httpx 默认会自动跟随重定向吗？
  固定流程：1 次回答调用，2.2 秒，输入 831 词元，输出 109 词元
    不会。与 `requests` 不同，HTTPX 默认不跟随重定向 [1]。默认情况下，HTTPX 对所有 HTTP 方法都不会跟随重定向 [2]。
[第 1 步] grep_docs({"keyword": "follow_redirects"}) → compatibility.md:19: response = client.get(url, follow_redirects=True) | compatibility.md:
[第 1 步] grep_docs({"keyword": "redirect"}) → advanced/transports.md:178: Or this example, which uses a custom transport and `httpx.Moun
[第 2 步] read_doc({"path": "compatibility.md", "start": 8, "end": 30}) → 8: ## Redirects | 9:  | 10: Unlike `requests`, HTTPX does **not follow redirects by defaul
[第 2 步] read_doc({"path": "quickstart.md", "start": 430, "end": 445}) → 430: [] | 431: >>> r.next_request | 432: <Request('GET', 'https://github.com/')> | 433: ``
  智能体：  3 次调用，3.8 秒，输入 3261 词元，输出 457 词元
    **不会。httpx 默认不自动跟随重定向。**

问：怎么给 httpx 设置代理？
  固定流程：1 次回答调用，3.7 秒，输入 1550 词元，输出 518 词元
    可以，以下是文档中提到的几种设置代理的方式。
（智能体的轨迹省略）
  智能体：  4 次调用，5.8 秒，输入 6756 词元，输出 732 词元
    httpx 设置代理主要有三种方式：

问：httpx 的超时分成哪几种？每种管什么？
  固定流程：1 次回答调用，2.6 秒，输入 991 词元，输出 208 词元
    httpx 的超时分为四种：**connect**、**read**、**write** 和 **pool** [1]。
（智能体的轨迹省略）
  智能体：  3 次调用，4.1 秒，输入 3731 词元，输出 546 词元
    httpx 的超时一共分成 **四种**（依据 `advanced/timeouts.md:45-61`）：

(For the fixed workflow only the answering call is counted; the rewrite calls were already cached.)

Both approaches got all three questions right. But the agent needed 3 to 4 model calls per question, about 4 times the input tokens of the fixed workflow, and one to two seconds longer.

The reason is easy to see: every step of the agent resends all the previous steps. Step 1 reads some grep results, so step 2's input includes them; step 2 reads two files, so step 3's input includes both files. The more steps, the longer the input.

For "look up one fact" questions like these, a single search finds the answer, so the agent's flexibility has nothing to do, and all that's left is the extra money and time.

What agents cost

• More expensive and slower. Multiple calls, and the context grows at every step.
• Unpredictable. The same question takes 3 steps this time and maybe 6 next time; this time it finds the right file, next time it may head further and further in the wrong direction.
• Hard to test and debug. Each step of a workflow has well-defined inputs and outputs that can be tested on their own; an agent's problems can only be found by digging through its execution trace.
• Riskier. The model can decide to call tools by itself. If the tools can modify data, send messages or spend money, one wrong decision or one successful attack (Lesson 8) has real consequences.

What agents are worth

Agents are worth it for tasks whose steps can't be decided in advance:

• What to look up depends on what the previous step found. For example, debugging an error: read the error message, then find the relevant source based on it, then find the relevant config based on the source.
• Several approaches may need trying. The first search finds nothing, so try other keywords or somewhere else.
• The tasks vary so much that you can't write a fixed workflow for each. A coding assistant, for example: users might ask it to fix a bug, add a feature, write tests or update docs.

RepoBot v2 can't answer "what is the default maximum number of redirects", because the answer isn't in the docs, only in the source. A fixed "search the docs, then answer" workflow simply can't do "if it's not in the docs, look in the source". That is where an agent is needed, and Lesson 9 builds it.

A checklist

Before building a new feature, ask yourself in order:

1. Can one model call do it well? For many tasks, a well-written prompt plus the right material is enough. If yes, stop here.
2. Can the steps be hard-coded in advance? If you can draw a fixed flowchart (A then B, if X then C), write it in code as a workflow. Each step can call the model, but your code controls the flow.
3. Must the next step be decided from intermediate results? Only if so, and the cases are too many to write out as branches, consider an agent.
4. Can you afford the cost of mistakes? Agents make mistakes. What can its tools do? Is there a way to have dangerous operations confirmed by a person first?
5. Are the cost and latency acceptable? One agent task can cost several times as much, and take several times as long, as a workflow.

A practical strategy: build it as a workflow first, and hand only the cases it can't handle to an agent. RepoBot, for instance, can run the fixed RAG workflow first and start an agent that can read the source only when retrieval shows "not in the docs".

Common misconceptions

"If it uses tool calling, it's an agent." The program in Module 03, Lesson 3 used tool calling too, but it was just "if the model needs the version, look it up once": a very fixed flow. Whether there are tools isn't the point; the point is whether the steps are decided dynamically by the model.

"Agents are more advanced, so they work better." In this lesson's experiment, the fixed workflow and the agent both got all three questions right, but the agent spent four times as much. On tasks with fixed steps, an agent won't be more accurate, just more expensive, slower and less predictable.

"Build one general agent that can do everything first." The more tools and the broader the task, the more easily the model picks the wrong tool or goes the wrong way. The more reliable approach in real projects: each agent handles one kind of task, and its tools relate only to that kind of task.

Exercises

1. Add a question to workflow_vs_agent.py: "what is httpx's default maximum number of redirects?" (the answer is in the source, not the docs). How does each approach answer?
2. Think of a task from your own work (handling customer tickets, compiling a weekly report) and run it through this lesson's checklist. Write down your conclusion: one call, a workflow or an agent? Why? There's no single right answer to this one.

Self-check

1. What is the fundamental difference between a workflow and an agent?

Who holds control. In a workflow, the steps and their order are hard-coded, and the model only handles the content of each step; an agent is given only a goal and tools, the model decides what to do next, and the number and order of steps aren't known in advance.

2. Why does an agent use several times more input tokens than a workflow to answer the same question?

An agent calls the model several times, and each call carries all the previous steps: the tool-call requests and the results they returned. The more steps, the longer each step's input, adding up to far more than a single call.

3. What kind of task is worth an agent?

One whose steps can't be decided in advance: what to do next depends on the previous result, several attempts may be needed, and the cases are too many to write out as fixed branches. Tasks that one call or a fixed workflow can do well shouldn't use an agent.