Prompting is cheap. Context is expensive.

There is an entire cottage industry of prompt engineering advice, and most of it optimizes the wrong layer. Magic phrases, persona incantations, “act as a world-class expert” preambles. In my work leading enterprise AI delivery, I have never seen a production system live or die on prompt wording. I have repeatedly seen systems live or die on context management: what gets loaded into the window, when, and at what cost. Prompting is cheap. Context is expensive. Efficiency is an architecture decision, not a writing style.

Tokens compound in loops

The reason context dominates is arithmetic, and it’s specific to agentic systems.

In a chat interaction, a bloated prompt costs you once. In an agent loop, it costs you on every turn. An agent plans, calls a tool, reads the result, and continues, and each of those turns re-sends the accumulated context. Every unnecessary instruction, every reference document loaded “just in case,” every verbose tool schema rides along on every single turn. A few thousand wasted tokens in the system prompt becomes tens of thousands of wasted tokens across a multi-turn task, and that multiplies across every task the system runs.

The failure modes compound the same way the costs do. Long, cluttered contexts don’t just cost more; they degrade behavior. Models attend less reliably to instructions buried in the middle of a large window, and stale or irrelevant material actively misleads. The bloated context you’re paying extra for is also making the system worse. That is the worst trade in engineering: negative returns at positive cost.

So the discipline that matters is not “write better prompts.” It is “put fewer, better-chosen tokens in front of the model at each moment.” That is an architecture problem, and it has architecture solutions.

Progressive disclosure

The core pattern is progressive disclosure: load instructions and reference material when the task needs them, not before.

The naive design front-loads everything. Every policy, every format spec, every edge-case instruction, every reference document goes into the system prompt, on the theory that the model might need it. The result is a context window that starts the conversation mostly full, with material that is irrelevant to the task at hand crowding the material that isn’t.

The better design gives the model a small core: who it is, what it’s doing, and an index of what else exists. Detailed instructions live in named, retrievable chunks. When the task turns out to involve refunds, the refund procedure gets loaded. When it doesn’t, those tokens are never spent. The model reaches for reference material the way a person reaches for documentation: on demand, guided by a table of contents, rather than by reading the entire manual before every task.

This is the same principle as lazy loading anywhere else in systems design, and it carries the same benefit beyond cost: what is in the window is relevant, which means attention lands where you need it.

Encode the workflow once

The second pattern is treating recurring instructions as an artifact, not a conversation.

Watch how teams actually use models and you’ll see the same workflow re-explained hundreds of times. Every session, someone types a variant of the same context: how we format this report, what our review checklist covers, which steps our deployment process requires. Each re-explanation costs tokens, and worse, each one drifts. Ten people explaining a workflow produce ten workflows.

The fix is to encode the workflow once, in a structured instruction file the system loads when that job appears: the procedure, the output format, the edge cases, the examples, written down, reviewed, and versioned. Reusable skills instead of one-off prompting. The economics are the economics of any other code: an upfront cost paid once, amortized over every future execution, instead of a re-derivation cost paid every time.

The quality effect matters as much as the cost effect. A written, versioned workflow can be improved deliberately. When it fails on an edge case, you fix the file, and the fix applies to every future run. An oral tradition of prompting can’t be debugged. It can only be re-told.

Right-size the model

The third lever is refusing to default to the frontier model for commodity work.

Agentic workflows are pipelines of unequal steps. Somewhere in the pipeline is genuine reasoning: ambiguous judgment, multi-step planning, synthesis. Surrounding it is commodity work: classify this intent, extract these fields, decide which of four routes applies, summarize this chunk. The frontier model handles all of it, and using the frontier model for all of it is like running your logging pipeline on the hardware you bought for training.

Matching model tier to task difficulty is one of the highest-leverage cost decisions available, precisely because agentic systems repeat their steps at volume. Smaller, faster, cheaper models handle the commodity steps at a fraction of the cost, often with latency benefits that improve the whole loop. The frontier model gets reserved for the steps that actually need it. The pattern is boring, which is a compliment. Tiering by difficulty is what every mature system does with every expensive resource.

Measure outcome per token, not vibes

None of these decisions should be settled by taste, and all of them can be settled by measurement. The unit that matters is outcome per token: task completion, answer quality, resolution rate, whatever your system exists to produce, divided by what it consumed producing it.

When someone proposes a prompt change, a new skill file, or a different disclosure strategy, the question is not whether the output “feels better.” The question is what happened to outcome per token on a fixed evaluation set. Some verbose additions earn their cost; a well-chosen example can pay for itself many times over in reduced retries. Some cherished instructions turn out to do nothing, and have been riding along on every request for months. You cannot tell which is which by reading them. You can tell by measuring. Prompt changes are changes to a production system, and they deserve the same empirical discipline as any other change.

The best prompt

The through-line in all of this is that the interesting work moved up a layer. The craft is no longer in phrasing a request. It is in designing the system that decides what the model sees: what loads when, what is encoded once versus re-sent, which model gets which step, and how you’d know if any of it improved.

Put differently: the best prompt is the one you never have to send twice.