Before you quote an agent job, write three numbers:
Minutes a person spends on it today
How often it happens per week
What a mistake costs if it ships wrong
The model price is almost never the price. The quote is the time you remove, minus the check someone still has to do. If you cannot name those three numbers, you do not have a job yet — you have a demo.
Before you build an agent, write one sentence that says what done looks like and one sentence that says what it must not do.
Example: Done = a 5-bullet brief of a public company page, with source links. Must not = invent numbers or send anything.
If you cannot write those two lines, the model will not save you. Spec first, then tools.
If a run fails, write the failure mode in one line before you change anything.
Useful labels:
Wrong scope (it did extra work)
Missing input (it guessed a fact)
Bad stop (it never finished or never stopped)
Unsafe action (it tried to send, spend, or publish)
Then fix only that line in the spec. Retrying the same prompt with a different model mostly repeats the same failure.
When an agent job feels "off," the default move is to swap models. That usually hides the real issue.
Look at the last 3 runs first:
Same input, different output? The prompt is under-specified.
Same mistake every time? Add a negative example ("do not do X").
Cost jumped with no quality change? You added tools or context you don't need.
Change one variable at a time. Model last, after the spec and the success criterion are tight.
Give the agent a hard resource limit up front.
Examples:
"Use at most 3 web searches"
"Output under 150 words"
"Spend no more than $0.25 in tokens on this run"
Without a ceiling the model expands the task. With one it focuses. Add the limit as the first line of the prompt and most runs get cleaner.
Before you hit run on any agent job, write one sentence that defines "done."
Examples:
"3 bullet points + source links, no more than 200 words"
"Draft email under 120 words that answers the client's last question"
"CSV with columns X, Y, Z and zero empty cells"
Then put that sentence at the top of the prompt and tell the model to stop when it meets it.
Most failed runs aren't model failures — they are fuzzy success criteria. Clear target first, then the agent has something to aim at.
When you sell or use an agent for a client job, start from the human time it saves, not the API bill.
Example: a research summary that used to take a junior 90 minutes. Even at a conservative $25/hr internal rate that is ~$37 of value. If the agent costs $0.40 in tokens and still needs 10 minutes of review, you have room to charge $15–25 and still look cheap.
Track both numbers on every job. The gap between human-hour value and token cost is the real margin signal.
Treat each agent job as a mini experiment:
Hypothesis: what you expect the agent to produce
Actual output (paste or link the file)
Cost (tokens + any tool fees)
Time (wall clock)
Pass/fail against the success criterion you wrote beforehand
After 10 runs you will see which prompts actually move the needle and which ones just burn budget. Most people skip this and wonder why results feel random.
Any agent that can spend money, send messages to clients, or change prices needs a hard stop before the irreversible step.
Pattern that works:
Agent drafts the action and the expected outcome
Human reviews and types APPROVE (or rejects with a reason)
Only then does the agent execute
Takes 30 extra seconds per run. Saves the "why did my agent email the wrong client" clean-up later.
Agents that mix "find out" and "do the thing" in one pass tend to invent steps or skip verification.
Split the job:
Research phase: gather facts, list sources, stop.
Action phase: only after you (or a human gate) approve the research output, run the next prompt that actually executes.
Keeps the model from hallucinating a next step it never checked. Costs a little more latency, saves a lot of cleanup.
