Stop Feeding Your Agent Everything

Every agentic tool wants a prompt, and if you are not careful you end up with a prompts/ directory growing next to your code, a new file every time you teach the thing another trick. I went through that phase. The files pile up, and then for any given task the agent is wading through a stack of instructions, most of which have nothing to do with the job in front of it.

The first fix is the obvious one: stop cramming everything into a single file. (That file has its own failure mode.) But splitting the pile by category only gets you so far, because the real problem was never where the instructions are filed. It is how much of them the agent has to swallow to do one small thing.

What actually helped was delivering the instruction at the point of use. The build prompt for a task lives on the issue for that task. When the agent runs, it gets the contract for this job, the goal and the constraints and what counts as done, and not the library of everything I have ever told it. That is context sharding: the right instructions, in the right place, at the moment they are needed, and not a second before.

This matters because a context window is finite, and it is not free. Every instruction you load that does not apply to the task at hand costs you twice. Once in the literal budget, and once in attention, because a model weighing a thick stack of mostly-irrelevant rules is a model more likely to reach for the wrong one. Relevance is not a nicety. It is a resource you spend, the same way you spend tokens or dollars.

Notice which variable moved. We pour our prompt-writing energy into what the instruction should say. The thing that changed the behavior was where it lived and when it arrived. The same words, delivered just-in-time on the issue, land differently than the same words buried in a monolith the agent re-reads from the top every single time.

It is the same shape as the rest of the setup. The issue is not only coordinating the work, it is handing the right payload to the right job. And context turns out to be one more thing you route, alongside which model takes a task and which provider gets it. You decide, ahead of time, what should arrive where.

Which is the actual point. Where you put the instruction is itself a design decision, and these days I give it as much thought as what the instruction says.