Skip to main content

all systems normal · status.trellisagents.example v2.3.0 · tokens pass through at $0 margin

trellis Agents

blog

When not to use an agent

We sell agent infrastructure, so believe us when we say it: most workflows shouldn't be agents. A decision framework, four disqualifiers, and the cost math nobody shows you.

· 7 min read · Sam Okafor — Co-founder & CTO, Trellis

We sell agent infrastructure, so read this with that in mind — and then believe us anyway: most workflows should not be agents. An agent is a loop that decides its own next step. That autonomy is the product, and it's also the cost: non-determinism, multiplied tokens, and a testing surface that grows with every tool you hand it. If a workflow doesn't need the autonomy, you're paying agent prices for pipeline work.

The one-question framework

Ask: can a competent operator write down the steps in advance? If yes, build a pipeline — a fixed sequence of LLM calls and code, each step testable on its own. Extract, classify, summarize, draft-then-template: all pipelines. The agent loop earns its keep only when the path genuinely varies per case — when step four depends on what step three discovered, and you can't enumerate the branches ahead of time. Debugging incident root-causes, multi-source research, open-ended operations triage: agent territory.

Four disqualifiers

Even when the path varies, these four conditions should stop you:

  • 1. Irreversible actions without a human gate. If the workflow's write-path can't be undone (payments, deletions, external messages at scale) and you can't afford an approval step, the failure math never closes. Guardrails reduce risk; they don't make an unreviewable action reviewable.
  • 2. A hard latency budget. Agent loops are slow by construction — plan, call, observe, repeat. If your user is waiting more than a few seconds, an agent in the request path will lose to a pipeline every time.
  • 3. No eval story. If you can't say what "correct" looks like well enough to grade it, you can't ship an autonomous loop that's supposed to achieve it. Build the pipeline first; let its outputs teach you the rubric.
  • 4. Volume without value asymmetry. Agents make sense when a good outcome is worth many times the run cost. A million low-stakes runs a month is pipeline economics, not agent economics.

The cost math nobody shows you

A single-call pipeline step costs one prompt and one completion. An agent run averages 6–12 model calls once you count planning, tool-result digestion, and self-checks — and the context window re-sends the growing transcript on every call, so token cost compounds roughly quadratically with loop length. Rule of thumb from our own metering: an agent run costs 15–40× the single LLM call teams budget for when they prototype. If the workflow runs 100k times a month, that multiplier is the difference between a rounding error and a line item your CFO circles.

None of this is an argument against agents. It's an argument for spending agent budget where autonomy pays — and for having the honesty, before you build, to notice when it doesn't. Half the teams that come to us leave with a pipeline design and a promise to come back when the branching gets real. They're our favorite future customers.

Takeaways

  • — If the steps can be written down in advance, it's a pipeline, not an agent.
  • — Disqualifiers: ungated irreversible actions, tight latency, no eval story, low value-per-run.
  • — Budget 15–40× a single LLM call per agent run; context re-send compounds the cost.
  • — Prototype the pipeline first; its failures tell you whether autonomy is actually needed.

← All posts

$ trellis estimate --honest

Still an agent-shaped problem?

Price the honest version in the configurator — per-run cost at your real volume, assumptions stated.

Sample site by SearchPod