Plan in the Cloud, Build Local: The Token Economics of AI Agentic Workflows

The teams running the most cost-effective AI agentic workflows today are not the ones with the biggest compute budgets — they are the ones who are deliberate about which model does which job. Expensive frontier reasoning for planning, cheap deterministic execution for building: that split is the lever that separates a lean agentic operation from one that burns budget on autopilot.

This is not an abstract optimization. It is the difference between a workflow that compounds value over time and one that runs hot, costs a fortune, and gets shut down before it ships anything.

Why Token Economics Are the Hidden Variable in Agentic Cost

Every time a large language model touches a task, it consumes tokens — both for the context it reads and the output it generates. Frontier models (the largest, most capable ones from major AI labs) are significantly more expensive per token than smaller, specialized, or locally-run alternatives. The cost gap is not marginal; directionally, it can be an order of magnitude or more.

That gap is irrelevant if you are running a single-prompt use case. It becomes the dominant variable the moment you are running agentic workflows: multi-step loops where models plan, generate, evaluate, and revise output — sometimes dozens of times per task.

The reason most agentic AI workflow cost experiments balloon is straightforward: engineers reach for the best available model for every step, because the best model produces the best output. That is true. It is also financially unsustainable at scale.

The smarter frame: not every step needs the best model. It needs the right model.

The Two-Layer Architecture: Cloud for Cognition, Local for Construction

Think of a well-structured agentic workflow as having two distinct layers.

The planning layer is where genuine reasoning happens. Decomposing a complex task into steps, evaluating ambiguous requirements, resolving conflicts between constraints, deciding which tools to call in which order — this is cognitively hard. It benefits directly from frontier-model capability. Spending money here is not waste; it is leverage. A poor plan executed flawlessly is still a poor plan.

The execution layer is where the plan runs. Calling a specific API with known parameters. Running a lint check. Generating a structured JSON payload from a template. Writing boilerplate code against an established pattern. Most of this work is deterministic — given the same inputs, the right output is not ambiguous. A smaller model, a locally-run model, or a deterministic script can handle it correctly and at a fraction of the cost.

The principle: use frontier cognition to define what to do, then use cheap execution to do it.

What "Local" Actually Means in Practice

"Build local" does not necessarily mean running a model on your laptop, though that is one valid implementation. It means routing execution-layer tasks to the least expensive compute that can handle them correctly:

• Locally-run open-weight models for pattern-matching, templating, and structured generation tasks where correctness is verifiable
• Smaller hosted API models (lighter-tier offerings from the same providers) for tasks that need API convenience but not frontier reasoning depth
• Deterministic scripts and tools for any task that is fully specifiable — file transforms, schema validation, code formatting, test execution
• Caching for any context that does not change between steps — reading the same reference document ten times per workflow run is pure waste; read it once, cache it, reference it

The common thread: every task you route away from a frontier model without sacrificing correctness reduces AI workflow cost while keeping throughput constant.

Agent Loops and How AI Agentic Workflows Map to This Pattern

Facet's Agent Loop model — Plan, Build, Check, Improve — maps cleanly onto the two-layer architecture.

Plan is frontier territory. This is where the loop decides what the next meaningful unit of work is, how to break it down, and what success looks like. The reasoning here sets the quality ceiling for everything downstream. Spending a few hundred tokens on a well-reasoned plan is almost always worth it.

Build is execution territory. Given a clear plan, building is largely mechanical. Whether it is generating a code diff, drafting a document section, or producing a structured output, the inputs and the expected output are both well-defined. Smaller models excel here.

Check sits in the middle. Some validation is deterministic (did the output parse as valid JSON? did the tests pass?). Use scripts and tools for that. Some validation requires judgment (does this actually solve the user's problem?). Route judgment-checks back to the planning layer; route syntax-checks to the cheapest tool that can do the job.

Improve is reasoning again. Deciding what to change, how to resolve conflicts in the feedback, which prior decision to revisit — this is planning work in a revision frame. Frontier models earn their cost here.

The payoff of thinking in loops is that the expensive cognition concentrates in the Plan and Improve steps, which are typically short relative to the Build steps. A loop that runs twenty build iterations on a solid plan is cheap to operate. A loop that calls a frontier model for every line of generated output is not.

Practical Patterns for Leaning Into Token Economics

These are the patterns we see working across agentic workflow builds.

Separate planning context from execution context. When you kick off a loop, have the planner model read the full context — the spec, the constraints, the history — and output a structured plan. Then strip the raw context from execution calls; pass only the relevant plan fragment. The execution model never needs to re-read the whole spec. This reduces per-call token volume substantially.

Write plans to disk, not just to prompt. An intermediate planning step that writes its output to a file or a cache creates a checkpoint. Every downstream execution step reads that file rather than re-deriving the plan from scratch. This eliminates re-planning latency and cost.

Use model routing at the call site. Rather than hard-coding a single model for the entire workflow, define routing rules: planning calls go to model A, generation calls go to model B, validation calls use a deterministic tool. This is a configuration decision, not an architecture one — most agent frameworks support it. Make it explicit.

Gate frontier-model calls on genuine ambiguity. Before routing a task to a frontier model, ask: is there a decision to be made here, or just work to be done? If the spec is clear and the output is verifiable, the task is execution. If the spec has gaps or the judgment call is non-obvious, it is planning. Treat that as a routing rule.

Measure cost per task, not cost per run. A single agentic run that completes in ten minutes and costs two dollars looks fine. A workflow that runs continuously and scales to thousands of tasks per day reveals the unit economics quickly. Track token spend per task-type from the start; it surfaces routing inefficiencies before they become expensive habits.

The Compounding Advantage

The teams that get this right early are not just saving money. They are building a more scalable operating model.

When execution-layer work is cheap, you can afford to run more check-and-improve cycles. More improvement cycles mean higher output quality. Higher quality means fewer human escalations and rework loops. The cost savings fund better iteration, which compounds into better results.

Conversely, teams that burn frontier tokens on every step hit a natural budget ceiling. They have to choose between running fewer tasks, running shallower loops, or accepting higher cost. None of those are good options when the goal is to scale AI agentic workflows across an organization.

Running lean on token economics is not a constraint on ambition. It is what makes ambition sustainable.

Getting the Architecture Right From the Start

The hardest part of this pattern is not the implementation — it is the discipline to make the routing decision explicitly rather than defaulting to the best available model.

This is where we see most organizations stumble. Engineering teams reach for frontier models because they produce better outputs in isolation, and that is correct. But the unit of optimization for an agentic workflow is not a single call — it is the full loop, measured by quality per dollar across thousands of iterations.

Building that discipline requires an architecture review early, before cost patterns are baked in. It requires tagging tasks by cognitive demand at design time, not trying to retrofit routing logic after the bill arrives. And it requires measuring the right things: token spend by task type, quality by layer, and loop efficiency over time.

These are engineering decisions with significant operational leverage. Getting them right is faster with a team that has built AI agentic workflows before — across different stacks, different task types, and different scale targets — and has already learned which shortcuts cost money later.

When you’re ready to explore, let’s talk it through.

FAQ

How Do I Know Which Tasks Belong in the Planning Layer vs. the Execution Layer?

Ask one question: is there genuine ambiguity in what the right output looks like? If yes, it is a planning task — it requires reasoning, and a frontier model earns its cost. If the output is verifiable (by a test, a schema check, or a known pattern), it is an execution task. The vast majority of volume in a running agentic workflow is execution; the planning layer is typically a small fraction of total steps, even if it is a larger fraction of total cost.

Does Running Smaller or Local Models Actually Produce Acceptable Quality for Execution Tasks?

For well-defined execution tasks, yes — consistently. The key qualifier is "well-defined." A smaller model given a clear spec and constrained output format performs as well as a frontier model on most generation and transformation tasks, because there is no ambiguity to resolve. The quality gap opens up on tasks that require judgment, context synthesis, or multi-step reasoning. Routing correctly means you are rarely asking smaller models to do that work.

What Is the Risk of Over-Optimizing for Token Cost at the Expense of Quality?

The risk is real and worth naming: if you route genuine judgment calls to a cheap execution model, you get cheap execution-quality answers to planning-quality questions. The output looks plausible and is wrong in ways that are not immediately obvious. The mitigation is to err toward the planning layer when a task's category is unclear, and to run explicit quality checks (ideally deterministic ones where possible) on execution outputs before they propagate further in the loop.

How Does This Pattern Scale as Workflow Complexity Grows?

It scales well because the routing logic is additive, not multiplicative. Adding a new task type to a workflow means classifying it once and adding it to the routing config. The planning layer capacity requirement grows slowly (more task types means more planning variants, but planning steps are short); the execution layer scales with throughput (more tasks, same unit cost). The pattern is specifically designed for workflows that need to scale — it becomes more valuable, not less, as complexity grows.