Do We Need an Agent at All?

Agency and intelligence are different quantities

Before the first technique, a distinction that unlocks all of them. The word agent carries its meaning openly: agency — the right to decide, to choose what happens next, to act. When we build an agent, that is what we are granting: decision rights over the path.

But look at what most problems actually need from us: intelligence — reading a messy email, judging a receipt, drafting a reply, weighing a preference. And here is the distinction:

AGENCY         the right to CHOOSE — what happens next,
               which action, when to stop.

INTELLIGENCE   the capacity to JUDGE — read, interpret,
               classify, weigh, draft.

An agent has both. But they are separable quantities —
and nearly all of the cost, latency, and unpredictability
comes from the first one.

You can deploy intelligence without granting agency.

That separation is the frame for every technique that follows: the question is never "do we need AI here?" — it is "do we need agency here, or only intelligence?"

The first technique is a question

We have the frame: intrinsic load set by formulation, extraneous load defined by lifetimes. And now the distinction above becomes a question to ask before anything else gets built:

An agent is a conversation whose LLM chooses what happens next —
intelligence WITH agency.

So before building one, ask:
does this problem actually require the choosing?

If the path is fixed — if judgment is needed only WITHIN the
steps, never BETWEEN them — then agency is pure overhead:
a deliberator hired to pick from a menu of one.

The insight comes straight off the lifetime chart. Some problems, charted, have a distinctive shape: every bar is one step long — each piece of information is born at one stage and consumed by exactly the next. Nothing lives across the task; nothing competes for a wall; there is no wall to manage:

The scheduler, without an agent

Make it concrete. The task: an email arrives proposing a meeting; reply with times that work. Real judgment lives inside this task — reading messy human text, weighing preferences, writing a natural reply. But watch where the judgment is, and isn't:

Five stages, each a tool — three of them tools made of prompts, two of plain code — each consuming exactly the previous stage's output. Look inside two of the prompt stages, because this is where the intelligence lives:

Between the prompts, plain code: the calendar intersection is set arithmetic — no mind required — and sending is a send. The whole task completes with no loop, no deliberation, no growing conversation. Nothing ever chose a path, because there was nothing to choose: the path was known before the email arrived.

What the loop would have cost

Now run the same task as an agent — a loop with tools, deciding each step — and put the two side by side:

The pipeline is cheaper and faster — but note the third win, because for production systems it often matters most: predictability. The pipeline cannot decide to skip the calendar. It cannot reorder the steps on a strange email. Its failure modes are the failure modes of its stages, not of a navigator — there is no navigator.

Judgment IN the steps, not BETWEEN them.

When the path is fixed, keep the intelligence and drop the
agent: cast each step as a one-step mind — a prompt with a
typed input and a typed output — and let the outputs hand
forward. Enormous intelligence per step; zero deliberation
between steps. Faster, cheaper, and the same shape every run.

There's a familiar frame for what we just built. The conversation is a play — and this play's script is already fully cast: who speaks at each stage, what they'll be asked, what form their answer takes — all written before the email arrived. The actors still act; each brings real interpretation to their scene. But no one on stage decides what scene comes next. A pipeline is a play with no improvisation about the plot — only within the lines.

When can you cast it this way?

The test, in three parts — and note that the first one is exactly what the lifetime chart shows at a glance:

That branching clause deserves emphasis: a deterministic branch ("if the list is empty…") keeps you in pipeline country — code chooses, instantly and for free. You cross into agent country only when choosing requires a mind: when what happened must be interpreted before anyone knows what should happen next.

The honest tail

One caveat, and it's one we've met before wearing other clothes. A pipeline handles the cases its designer imagined — and the world ships the 1%. The email that proposes times and asks to reschedule a different meeting. The reply-all with three conflicting proposals from two people. A pipeline meeting the case outside its path doesn't improvise — it does something worse: each stage processes its slice locally-correctly, and the composed result is confidently wrong.

The remedy is not "use an agent everywhere after all." It is the same move as covering the tail with a handoff: give stages a way to say this is outside my brief — and route those cases to the expensive machinery:

Every stage may return NOT_MY_CASE(reason) instead of output.

The pipeline handles the 99% at pipeline prices.
NOT_MY_CASE routes the 1% to a navigator — an agent, or a
human — with the stage's reason as the brief.

Enumerate the head. Hand off the tail.
The pipeline and the agent are not rivals; they are the
cheap path and the exception path of one design.