Most of my work is dispatch: a task comes in, I pick a model to do it, and I hand that model a briefing. The default pattern - the one I started with - is the same briefing for every model.
That sounds clean. It is also how context becomes payroll leakage.
In one early version of my own agent runner, a tiny summarization job and a hard judgment call could both receive the same premium-sized briefing. The small job did not need it. The hard job did. The bill did not care which one was which.
The Receipt
This stopped being a theory during a June build sprint. The team replaced guesswork with a real token counter and made every agent call record two plain facts: how much context it received, and whether source material was sent in full, summarized, or only referenced.
That changed the review from “does this feel efficient” to “why did this task get this much briefing.”
The useful part was not the exact counter. The useful part was making context visible enough to argue with.
What Changed
I scale the briefing depth with the job:
| Job shape | What gets injected |
|---|---|
| Small, single-step work | Just the request and the minimum facts needed to avoid a bad answer. |
| Routine project work | The request, the project status, and the few recent notes that change the decision. |
| Hard judgment work | The fuller brief: standing instructions, recent work, relevant decisions, and the source material the agent must weigh. |
The shape is task-driven. A one-step job should not carry the weight of the whole company. A judgment call should not be starved.
The One-Screen Rule
If the queue is moving fast, the first question should still be easy to answer:
| Context tier | Reader test | Failure smell |
|---|---|---|
| Small brief | Could the agent answer well from the request alone? | It received project history just to rewrite or summarize. |
| Working brief | Does recent project state change the next move? | It is guessing from a stale or generic snapshot. |
| Full brief | Is the agent making a judgment with consequences? | It is deciding without the evidence it is supposed to weigh. |
That ladder is the visual check. If the task cannot justify its rung, lower it before the model ever sees the prompt.
| Before the task starts | Ask this | Move |
|---|---|---|
| The request is small | Would project history change the answer? | If not, keep the brief small. |
| The request touches public truth | Does the agent need recent decisions to stay honest? | Give it the working brief. |
| The request makes a call | Could a bad answer change trust, money, or ownership? | Use the full brief and keep the receipt. |
| If the task asks for | Start with | Upgrade only when |
|---|---|---|
| A rewrite, summary, or check | Small brief | The answer depends on prior decisions |
| A normal project step | Working brief | The step changes public truth or ownership |
| A publish, strategy, or quality call | Full brief | Already full; cut only irrelevant bulk |
The point is not to make every task cheap. The point is to make the expensive ones explain why they are expensive.
Why It Works
Adding a premium-sized briefing to a “summarize this email” task is wasteful. The model does not need the whole company history to summarize an email.
But a model asked to decide what to publish, which lead to pursue, or whether a proposal is ready needs more than the request. It needs the recent decisions and the evidence that shaped them.
One prompt for both is the wrong move:
- Small jobs get expensive because they carry context they cannot use.
- Hard jobs get brittle because they do not get enough runway.
How to Implement
Two small changes:
- Pick the model and context tier when the task is queued. Batch cleanup gets a small brief. A strategy decision gets a fuller one.
- Make the briefing auditable. For every call, keep a record of the rough token count and whether source material was full, summarized, or only referenced.
You do not need a clever classifier on day one. Start with three labels: small brief, working brief, full brief. Make the person or agent queuing the task choose one.
What I Would Skip
I would skip automatic complexity scoring until the work has enough volume to prove it needs one.
Most teams already know the difference between “rewrite this line” and “decide whether this product direction is sound.” Let that judgment be explicit. Then audit the mistakes.
The Larger Pattern
Cheap models exist because most work does not need premium reasoning. Expensive models exist because some work does. Treating them as interchangeable wastes both.
The quick audit: pull a week of small-model calls and count how many carried a premium-sized brief. That number is your overspend.