A chat prompt and an agent prompt solve different problems, even when the same person writes both. In chat, the model answers and hands the turn back. An agent picks its own next step, which means it will keep repeating any mistake in the prompt on its own, with no one stepping in.
How an agentic loop differs from chat
In chat, the cost of an imprecise instruction is one imperfect reply. The user corrects it, the model asks a follow-up, the conversation moves on.
In an agentic loop, the model reads its own prompt at every iteration: before calling a tool, after seeing the result, before the next decision. An imprecision in the system prompt is not a one-off, it multiplies across steps. An agent that slightly misunderstood the goal will, after ten steps, have drifted much further from it than a chat partner ever could in one reply.
The consequence is simple, if counterintuitive: wording matters more for an agent than for chat, not less.
Write the goal, not a step-by-step script
A common mistake is writing the agent a detailed list of steps, like a script. That works until the first deviation from the plan: a missing file, a failing test, an API returning an unexpected shape. A rigid instruction has no room for that, and the agent either gets stuck or improvises blindly.
Describing the goal and the success criterion works better: what must be true at the end, not exactly which commands get there. "All tests in the package pass" beats "run command X, then Y, then Z." The agent picks its own steps, and if one path fails it tries another, without straying from the actual goal.
Constraints matter more than capabilities
In a chat prompt you describe what the model can do. In an agent prompt, what matters more is what it must not do.
An agent with tool access can delete a file, hit an external service, or burn budget on a thirty-call chain if you never said otherwise. Access permissions are not enough. Explicit boundaries need to live in the prompt itself: which files are off limits, which actions require confirmation, what amount of work counts as reasonable for one task.
A good check: read the prompt and ask what would stop the agent from wandering somewhere you never intended. If there is no answer, the constraints are implied, not written down.
A stop condition is not optional
Chat has a natural stop condition: the model answers, the turn goes back to the user. An agent has no such built-in limiter, and without an explicit one it will keep trying until it hits a step or token ceiling, assuming one even exists at the code level.
The prompt should spell out explicit end conditions: when the task counts as done, when to pause and ask the user, and when to give up and report failure instead of trying forever. Skip that last one and an agent that cannot solve the task will keep attempting it, and every attempt is tokens spent.
How to describe tools for an agent
A tool is as much a part of the prompt as the system instruction. Its name and description shape when the model expects to call it, and a bad description causes wrong calls just as reliably as a bad instruction does.
One rule that holds up: a tool description should answer three questions with no room for guessing. What it does, which parameters are required, what comes back on failure. If a tool can fail in several distinct ways, describe them separately, otherwise the agent will treat every error the same way, and usually the wrong way.
Common mistakes in agent prompts
A prompt copied straight from a chatbot rarely works as-is: it has no stop condition and no constraints, because chat never needed them.
A goal that is too vague, with no success criterion, leaves the agent guessing when the task is done, so it either stops too early or keeps working past the point of usefulness.
Missing a step or token budget in the prompt itself is a frequent cause of runs that turn out unexpectedly long and expensive. State a sane attempt limit explicitly and tie the stop condition to it.
In short
Chat and an agent read a prompt differently: chat once, an agent at every step. That is why the goal and success criterion matter more than a step-by-step script, constraints matter more than a list of capabilities, and a stop condition is not optional but a required part of the prompt. Skip it and the cost of a mistake grows with every extra loop.