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? Three places the boundary lands 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. The tell 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: Can the task be expressed as steps with a known order? Pipeline with the LLM as a step — not an agent. Does the agent invoke known tools with expected outputs? A single governed agent, thin on top of a deterministic core. Do you need to route mid-task to unexpected states? Only then a real runtime, and only if you accept owning its observability, limits, and audit trail as first-class work. Is the failure non-recoverable? Then don't put an agent in the loop at all. A wrong tool call inside a runtime can hurt you faster than a slower deterministic path ever will. 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.