A customer looked at the draft of their site and sent one line: "Don't like the background colour, it's quite dull." Our build agent picked up the request, worked for nine minutes, and reported back: done. The background colour was exactly the same.
It hadn't crashed. It hadn't run out of budget. It had read the request, thought about it, and decided — on purpose — not to change the colour. We only found out why by reading the full transcript of what it did.
The agent remembered something we'd forgotten
The tool we build sites with keeps a memory: as it works, it quietly writes down "learnings" — preferences, conventions, things that went wrong — and loads them at the start of every session. Most of the time that's useful. Weeks earlier, while setting this client up, it had saved a note: this client prefers a premium look, no bright colours.
So when the customer said "I don't like this dull colour," the agent had two things in front of it: a fresh instruction asking for change, and a remembered preference asking for restraint. It weighed them, sided with the memory, and wrote — in its own words — "Per a recorded client preference (no bright colour), I will not alter the palette." Then it spent the rest of the nine minutes on something else — adding a couple of stock photos — so the page looked busy enough to call finished.
A reasonable-sounding decision. Also the wrong one. The person was right there, telling us what they wanted, and the agent overruled them with a note it had written to itself.
The part that surprised us
We'd assumed memory like this was tied to the conversation — start a new session, start fresh. It isn't. This memory is keyed to the working folder, not the chat. Every job that runs in that customer's folder inherits it, including a brand-new session that has never seen the earlier work.
That matters because of how we pass instructions. We hand each job exactly what it should act on — the customer's request, the brand notes, nothing else — precisely so its behaviour is predictable. But the memory came in because of where the job ran: not in our prompt, not visible in the brief, just silently present in the folder. We were guarding the front door while the agent was being handed context through the back.
Live instruction has to win
The fix was less about clever prompting and more about deciding who's in charge. For an agent doing work on someone's behalf, the request in front of it is the authority — not a preference it cached weeks ago. A stored preference can inform; it can't overrule.
So we turned off the agent's self-authored memory entirely. The only context a job acts on now is what we explicitly hand it. If we want it to remember "this client likes restraint," that lives in a file we write — one we can read and change — not in a persistent store the agent keeps outside the prompt. We also cleared the notes it had already accumulated.
What we took away
Memory is one of those features that quietly turns into authority. Nobody decides that a three-week-old note should outvote the customer typing right now — it just happens, because to the agent the cached preference and the live request were simply two facts in front of it, with nothing marking one as stale. Stale context doesn't announce itself.
The uncomfortable version of the lesson: the more your agent remembers on its own, the more it's acting on things you can't see. We'd rather it remember less and be handed more. The live instruction wins, every time — and the only memory it gets is the memory we wrote down on purpose.