Under a set of assumed parameters, a 10-step task requires a cumulative input of roughly 27,800 tokens with ReAct, compared with about 7,200 tokens using Plan-and-Execute—a 3.9x difference. This is not a product benchmark, but it exposes a critical fact about deploying Agents: the way a task is planned directly determines model costs and whether the workflow spirals out of control.
What this is
ReAct is an alternating “reasoning-action” pattern. After each step, the model uses the preceding process to decide what to do next, making it suitable for exploratory tasks with few steps and an uncertain path. Plan-and-Execute first produces a multi-step plan, then executes it item by item, making it better suited to repetitive tasks with stable workflows. Hierarchical planning sits between the two: it first divides the task into stages, executes tasks within each stage, resets context between stages, and reassesses the plan.
These three approaches are not a succession in which newer methods replace older ones. ReAct rereads history at every step, so input volume accumulates sharply as the number of steps rises. Plan-and-Execute front-loads costs into the planning stage and avoids repeatedly passing context, but it also requires the initial plan to be sufficiently accurate. The article proposes a practical boundary: teams generally do not need to add a planner for tasks of three steps or fewer, but for tasks of ten steps or more, they should seriously evaluate fixed-plan approaches.
Industry view
We believe the article’s value lies not in prescribing a “best architecture,” but in pulling Agent projects back from discussions of model capability and toward discussions of cost structure. When evaluating an AI application, enterprises should track more than accuracy. They should also record the number of steps required to complete a task, task stability, how often plans must be redone, and the context length of every call. For enterprise services with fixed workflows and frequent usage, planning first and executing afterward is often more economical. For tasks with vague requirements that demand real-time judgment, fixing the plan too early can instead magnify errors.
The risks are equally clear. The token figures in the original article come from an assumed model, and real-world differences will also depend on output length, tool responses, caching mechanisms, and model pricing. Fixed plans have another obvious weakness: if conditions change midway through execution, the system may continue down the wrong path. The more detailed the plan, the farther an error can propagate. Plan-and-Execute therefore should not be interpreted as “generate once and execute forever.” Critical tasks still need to support replanning and human review.
Impact on regular people
For enterprise IT: When procuring Agent services, technical teams should ask vendors to explain the number of task steps, how context is handled, and how failed attempts are retried rather than settling for a single successful demo. Only a transparent cost structure allows an organization to determine whether a system can run sustainably over the long term.
For individual professionals: If an AI assistant must ask repeated questions and frequently adjust its approach, ReAct-style interaction is more natural. For fixed processes such as expense reviews or document archiving, making a checklist first and then processing items in batches usually saves call costs. The chosen method does not need to be sophisticated; the first question is whether the task has stable steps.
For the consumer market: Per-use AI products are not necessarily more expensive than subscriptions, since underlying call volume is only one part of price. As planning, memory compression, and batch execution become standard product capabilities, users are more likely to encounter assistants that are both cheaper and more reliable. But the stronger the “automatic completion” claim, the harder it becomes for users to notice the impact of a flawed plan.