Every time a new model ships, the same reflex kicks in: maybe this one fixes it. The agent that wrote generic copy, the assistant that missed the point of the brief, the pipeline that needed babysitting. Surely the smarter model solves it.
Months of running agents in production have made me confident in an unfashionable opinion: it almost never does. When one of my systems fails, and I go read the transcript, the failure is nearly always the same shape. The agent did something reasonable given what it knew. It just knew too little.
Failures are context failures
An agent that writes copy without the banned claims list will eventually write a banned claim. Not because it is dumb, but because nobody told it. An agent that has never seen the past winners will produce the industry average, because the industry average is exactly what it learned from. An agent that does not know why the last three variations were killed will happily produce a fourth.
Read enough of these transcripts and the pattern becomes impossible to unsee. The model had the capability. The system withheld the context. I stopped asking "which model should this run on" and started asking "what would a sharp new hire need to know to do this job," because that is the actual specification. A new hire with the product facts, the voice guide, ten examples of great, ten examples of terrible, and the reason each terrible one failed will beat a genius wandering the building on day one. Agents are the same, minus the coffee.
What good context looks like
Good context is not a bigger prompt. It is specific, curated, and owned.
The facts of record: what the product does, what it costs, what can and cannot be claimed. The standards: what good looks like here, with examples, and what gets work killed, with reasons. The constraints: format, length, compliance, the sentence legal rewrote and why. And the feedback loop: what happened to the last batch, so the next batch is not a rerun of it.
Each of my agents gets this as a matter of wiring, not hope. The video pipeline knows the brief format because there is one brief format. The review bench holds the standards because the standards are written down. When something is wrong in the output, my first question is not "why is the model bad." It is "which document is missing or stale." That question usually has an answer I can fix in ten minutes.
Small beats big
This changes the architecture. If context is the binding constraint, the right unit is not one giant assistant that does everything. It is many small agents, each with a narrow job and a complete picture of that job.
A narrow agent can hold everything relevant in view at once. Its performance is legible: when the copy judge fails, I know it was the copy judge, and I know which standard it applied. Its context stays curated, because a narrow job has a knowable set of documents. And it is replaceable, because the value is in the wiring and the context, not in the particular model running it. I have swapped models under agents without touching anything else, and mostly nothing changed. That is what it feels like when the system, not the model, carries the intelligence.
The orchestration layer, the thing that routes work between these narrow agents, matters more than any single one of them. That is where the actual shape of the business lives.
The checklist
Before blaming the model, five questions.
Does the agent have the facts a new hire would get on day one? Does it have examples of great and terrible, with the reasons? Does it know the constraints, all of them, in writing? Does it see the outcome of its last output? And is its job narrow enough that all of the above fits?
If any answer is no, the next model will not save you. Fix the context. It is cheaper than waiting, and unlike the model, it is yours.