№ 008agents · architecture filed may '26

When to use an agent vs. a single call.

A two-minute decision tree. Most "agents" should've been a function.

This is the two-minute test for deciding whether a problem needs an agent or a single LLM call. An agent is a function that needs to recover from itself. Most "agent" problems don't qualify.

What you'll have when you finish: a printed decision tree pinned to your monitor, a cost-per-task spreadsheet template tracking call vs. agent spend, and a function-vs-agent comparison table you can paste into any team discussion.

Cost of getting this wrong: 5–10× higher per-task spend, slower latency, harder debugging. Cost of getting it right: a function you write in an afternoon and forget for a year.

01

The stack.

  • 01Anthropic API — single calls + tool usedaily
  • 02Inngest — durable jobs for the real agentsdaily
  • 03A spreadsheet — honestly, for triaging which is whichweekly
  • 04Langfuse — measure cost-per-decisionweekly
  • 05This decision tree — two minutes per problemcontinuous
02

How to apply it.

GOAL: one step or many? │ ├─ one step ─────────────────▶ SINGLE CALL │ (with tool use, if needed) │ └─ many steps │ └─ needs outside state between steps? │ ├─ no ─────────▶ SINGLE CALL │ (with longer context) │ └─ yes │ └─ could fail halfway & need to resume? │ ├─ no ────▶ JOB (function + steps) │ └─ yes ────▶ AGENT — bound it tight
  1. 0130 sec

    Is the goal one step or many?

    If the answer is "one step — read the input, produce the output," it's a single call. Tool use included. One step + tools is still one step.

    Many steps means: the second step's input depends on the first step's output, in a way you can't enumerate up front.

  2. 0230 sec

    Does it need outside state between steps?

    If it can hold everything in one prompt → single call. If it needs to fetch, update, and refetch some database in the middle → maybe an agent. Probably a job with two function calls.

    A job is not an agent. A job is a function with steps you wrote down.

  3. 0330 sec

    Could it fail halfway and need to resume?

    The real agent test. If a failure mid-run requires interpreting what got done, deciding what to do next, and proceeding — you need an agent.

    Most "agent" problems people pitch don't pass this test. They pass step 01 or 02 and stop.

  4. 0430 sec

    If yes to all three — agent. Bound it tight.

    One sentence goal. Five tools max. Three hard limits (steps, time, cost). Three kill-switches. Full trace. (See guide № 002 for the build.)

    If no to any → function. Move on. Save the agent budget for the problem that actually needs one.

Function (single call)
Agent (multi-step)
1 LLM call, maybe with tools
Many LLM calls in a loop
Deterministic JSON output
Probabilistic output
$0.01 – $0.20 per task
$0.50 – $20 per task
1–5 second latency
10 sec – 20 min latency
Fails loudly, retry-friendly
Fails quietly, needs full trace
Fits 80% of real problems
Fits 20% of real problems
03

What we stopped doing.

  • ×Calling it an "agent" because it uses tool use. Tool use is a feature of the call, not a category.
  • ×Multi-agent setups for single-agent jobs. Most "swarms" are decoration.
  • ×Vague goals. If you can't write the goal in one sentence, the agent can't either.
  • ×Agents for things that should be a cron + function. A scheduled job isn't an agent.
  • ×Building an agent before testing the function version. The function version often works fine.
04

The take.

An agent is the right tool when the problem has uncertainty across steps. Not when the prompt is long. Not when the input is fuzzy. Not when you want to show off.

Steal one thing: write the two-minute test on a sticky note. Stick it to your monitor. Most calls go faster after that.

Related stackThe agent stack →
Next in the libraryBrowse all 12 guides →

Need this done for you? The author works on this exact thing with audit clients at austinaiguy.com.