Main idea

A script that calls an assistant to do a mechanical task — extract from an exchange the decisions to record and return them as JSON — gets a correct answer or not depending on the directory it was launched from. Launched from the project, the assistant loads that project's CLAUDE.md and starts obeying the writing rules it finds there, instead of returning the requested structure. Launched from /tmp, it finds nothing and does what it was asked.

The current directory is therefore not an invocation detail: it is part of the prompt, invisible in the prompt. The very instructions that make a conversational agent useful — conventions, tone, prohibitions, deliverable formats — are noise for an agent used as a function.

Hence a rule of isolation: a utility agent is called from a neutral place, chosen for what it doesn't contain. Neutrality is a property of the place of execution, not of the prompt.

Why it matters

The failure is hard to diagnose because it doesn't look like a failure. The model answers, the answer is plausible, it is simply malformed or too talkative — and you suspect the prompt, the model size, the temperature, everything except the path.

More broadly: two uses of the same agent don't have the same need for context, and the context that serves one degrades the other.

Nuances and limits

Isolation also cuts off what would have been useful. An agent launched outside the project knows nothing of its naming conventions, and if it has to write into the project's files, you will have to tell it explicitly.

And the inheritance mechanism depends on the tool: what gets loaded automatically, and from which root, isn't the same everywhere.

Open questions

• How do you give a utility agent the part of the project context it needs, without giving it the rules meant for the conversational agent?