They ask: How do you manage context when working with an agent on something large?
You say: I treat the window as a budget and decide the split before I start.
A small share at the top goes to rules and standing instructions. The bulk goes to the work itself. And I hold back a reserve that I do not spend on work at all.
That reserve is the part most people skip, and it is the part that matters. Everything is fine until something breaks. Investigating a failure costs room, often more than the work did, because now you are pulling in logs and error output and the file you thought was fine. If you have filled the window, you arrive at the hard part with nothing left and the agent starts dropping the instructions you set at the beginning.
So I plan for the failure rather than the happy path.
The answer that ends the conversation early: "we use a model with a large window." Bigger windows move the wall. They do not remove it, and they make it easier to fill the space with material nobody needed.
They ask: Should we just give the agent all the documentation and let it figure out what it needs?
You say: No, and this is the most common mistake I see.
There is an instinct to be generous. Give it the requirements, the schema, the style guide, the previous tickets, all of it, so nothing is missing. But every one of those pages is spent room. You can hand an agent so much preparation that it has nothing left to do the job with.
The discipline is deciding what this specific task actually needs and giving it that. It feels less thorough. It produces better work.
The answer that ends the conversation early: "more context is better." It is a budget. Nobody thinks more spending is better when you say the word budget out loud, and that is exactly why I use it.
They ask: What is context poisoning?
You say: It is when something enters the working context that is wrong or irrelevant, and the agent then treats it as true for everything that follows.
It comes from three places. It can come from earlier in the conversation, where you discussed a different approach that was abandoned but is still sitting there. It can come from the model's general training, where it pattern matches to something that has nothing to do with your system. And it can come from the agent's own earlier output, which is the one people miss. The agent writes a note, the note contains a small error, and from that point on the note is treated as a source.
That third one compounds. Everything after it is built on it.
The answer that ends the conversation early: describing it only as bad user input. Half the sources are internal, and the internal ones are harder to see because they arrived in the agent's own confident voice.
They ask: How do you stop an agent doing something destructive?
You say: You write the rules down in a file it reads before it does anything, and you write them as prohibitions.
Not guidance. Not preferences. A short list of things it must never do. Never touch production data. Never send anything externally. Never delete without showing me first. Then you require evidence before it may report a task complete.
I did not write that file until after an agent deleted a project of mine and told me the tests had passed. I would like to say I wrote it in advance out of good judgement. I wrote it the week after, out of a bad morning.
The answer that ends the conversation early: "we tell it to be careful in the prompt." A prompt is a request in a conversation that will be full in an hour. A rules file is read at the start of every session, and it is the only version of this that survives a long day.