When Should You NOT Use an Agent?

A developer argues that agents are often overused and that teams should consider deterministic pipelines for well-scoped tasks. The post emphasizes that agents defer decisions to a runtime, which can introduce nondeterminism and complexity, and suggests that the real question is where to place the judgment boundary. The author offers heuristics such as constraining before automating and evaluating whether the deferral is actually beneficial.

Everyone is asking "should we use agents?" The real question is "when should we NOT?" I keep seeing teams bolt an agent on because it's the hot thing — then discover they reinvented a state machine with worse debugging. Agents don't solve a problem by existing. They are a mechanism for deferring decisions to a runtime . When your inputs, tools, and failure modes are well-understood, that deferral buys you nothing but nondeterminism. The architecture question is not "LLM or not." It is: where does the judgment boundary sit? A single agent is a program. For a well-scoped task with a known toolset, you don't need a loop at all. You need a deterministic pipeline — with the LLM as one component, not the orchestrator. The moment you need a loop, you're building a runtime. A runtime is a different beast. It has observability, tool permissions, credit and rate limits, and a way to explain what it did after the fact. That's not "more AI." That's distributed systems with a language model as the cognitive layer. The expensive failure is capability you never signed up for. Agents surface things you didn't design for: open-ended tool calls, emergent side-effects, scale that hits budgets or audit. This is where maturity shows — not in the cleverness of the model, but in the constraints around it: entitlements, approval, observability, evals that cover the failure path, not just the happy path. Most of what teams call "agent architecture" is a decision-making boundary placed in the wrong spot, papered over with more layers. If you reach for a framework, an orchestrator, a runtime — stop and ask what you're actually deferring, and whether that deferral is working or just making the system harder to debug. A few heuristics I use before building: Constrain before you automate. The agent looks cooler; it's also much harder to explain three months from now. So: when you're scoping a new system, what makes you reach for a deterministic pipeline instead of an agent — or the other way? I'd like the rules teams actually run with, not the ones they present in talks.