How do you decide which tasks get a fixed workflow, plan-and-execute, or ReAct?

## The question that orders everything Before the first tool call, how much of the step sequence do you already know? That single question sorts nearly every task into one of three buckets, and it is the framing a principal is expected to bring — because the failure mode at this level is not choosing the wrong loop, it is choosing an agent at all when a function would do. ## Bucket one: you know all the steps A shipment-status lookup does the same three things every time: resolve the tracking ID, fetch the status, render a reply. There is no decision for a model to make about sequence. Implement it as code. If you want natural-sounding phrasing, make one model call inside the last step — that is an LLM feature, not an agent. What you avoid is substantial: a fixed workflow has a predictable cost per request, a predictable latency, a stack trace when it fails, and no possibility of the system deciding to call a tool you did not intend. Every one of those properties is expensive to recover once a model owns the control flow. The honest baseline for any agent proposal is "what does the non-agent version cost and score?", and teams that skip it routinely ship agents that are slower, dearer and less reliable than the `if` statement they replaced. ## Bucket two: you know the shape, not the content A monthly reconciliation across four systems is the same seven steps with different identifiers; a customer onboarding is the same checks in the same order with different documents. Here the sequence is derivable upfront but the arguments are not, so a planning call that emits a step list with substituted values gives you determinism, concurrency across independent steps, and — often the deciding factor — a plan that a human or a policy check can inspect before anything with side effects executes. In regulated domains that inspectable artifact is worth more than the token saving. ## Bucket three: you cannot enumerate the steps Incident diagnosis, exploratory research, open-ended code changes. What you query second is determined by what the first result said. Any upfront plan here is a guess in a structured costume, and its determinism is worse than useless because it is deterministic about the wrong steps. Run ReAct, budget for the round trips, and invest in observability instead of structure. ## Second-order considerations that move the line **Reversibility.** The more irreversible the actions — money moves, customer emails, production writes — the more you want a reviewable plan or plain code, and the less you want a model choosing freely at each step. Adaptivity is cheap to grant on read-only work and expensive on write paths. **Variance tolerance.** Agents produce a distribution of behaviours, not one behaviour. If your product promises a consistent experience or your contract promises a response time, that distribution is a liability, and a strategy that narrows it earns its constraints. **Operational surface.** Every strategy you run is a distinct failure mode, a distinct eval harness and a distinct on-call story. A portfolio with all three is legitimate for a large product and pure overhead for a small one. Consolidating on two is usually the right organizational answer even when three would be marginally better per task. **Migration in both directions.** The interesting move is not just workflow-to-agent. When traces show a ReAct loop converging on the same path for 95% of inputs, that path has become knowable and should be promoted to a plan or to code, with the loop kept only as the fallback for the tail. Teams reliably do the first migration and almost never do the second, and that is where a lot of avoidable cost lives. ## How to actually run the decision Start at the cheapest strategy that could work and escalate only on measured failure against a real eval set. Escalation criteria should be written down before you build: "if the fixed workflow cannot handle more than 80% of inputs without a human, we plan; if generated plans complete without revision less than 70% of the time, we loop." Without those numbers the decision defaults to whatever is fashionable, which in 2026 means everything becomes an agent. And be honest that this is contested ground. There is no settled industry answer on where the boundaries sit; what is defensible is having a stated rule, a baseline you measured against, and a willingness to move a task back down the ladder when the evidence says its uncertainty was smaller than you assumed.