A chat prompt and an agent prompt solve different problems, even when one person writes both. In chat, the model replies and hands the turn back to you. An agent chooses its own next step, so any flaw in the prompt gets repeated on its own, step after step, with nobody stepping in.
Chat versus an agentic loop
In chat, a loose instruction costs you one imperfect reply. You correct it, the model asks a follow-up, the conversation moves on.
In an agentic loop the model rereads its own prompt on every iteration: before a tool call, after the result, before the next decision. There are no one-off errors here. An imprecision in the system prompt multiplies by the number of steps. An agent that slightly misread the goal will be much further off after ten steps than a chat partner after one reply.
The conclusion is simple, though intuition says the opposite: wording matters more for an agent than for chat.
Write the goal, not a step-by-step script
Many people hand an agent a detailed list of steps, as if for a script. That holds while everything goes to plan. The moment something deviates (a file is missing, a test fails, an API returns an unexpected shape), a rigid instruction has nothing to say, and the agent either gets stuck or improvises blindly.
Describe the goal and the success criterion instead: what must be true at the end, not which exact commands get you there. "All tests in the package pass" works better than "run command X, then Y, then Z." The agent picks the steps, and if one path fails it tries another without leaving the bounds of the goal.
Constraints carry more weight than capabilities
In a chat prompt you say what the model can do. In an agent prompt it matters more to say what it must not do.
Unless told otherwise, an agent with tool access can delete a file, call an external service or burn the budget on a chain of thirty calls. Access permissions alone are not enough. Put the boundaries in the prompt itself: which files to leave alone, which actions need confirmation, how much work counts as reasonable for a single task.
A quick test: reread the prompt and ask what would keep the agent from going somewhere you never meant it to. No answer? Then the constraints are implied, not written down.
You cannot skip the stop condition
Chat has stopping built in: the model answers and the turn passes to the user. An agent has no such brake. Without an explicit condition it keeps trying until it hits a limit on steps or tokens, and only if a limit is set in code at all.
Spell out the end conditions in the prompt: when the task counts as done, when to stop and ask the user, and when to quit and report failure. The last one matters most. Without it, an agent that cannot solve the task will try again and again, and every attempt costs tokens.
How to describe tools for an agent
A tool belongs to the prompt as much as the system instruction does. Its name and description set the model's expectation of when to call it, and a bad description triggers wrong calls just as a bad instruction does.
The rule is simple. A description should answer three questions with no guessing: what the tool does, which parameters are required, and what comes back on error. If a tool can fail in several different ways, describe each one separately. Otherwise the agent treats every error alike, and often wrongly.
Common mistakes in agent prompts
A prompt carried over from a chatbot without changes rarely works: it has no stop condition and no constraints, because chat never needed them.
A goal that is too broad and has no success criterion leaves the agent guessing when it is done. It either stops early or keeps working past the point of usefulness.
No step or token budget in the prompt itself? That is a frequent cause of runs that turn out unexpectedly long and expensive. State a sensible attempt limit and tie the stop condition to it.
The short version
Chat reads a prompt once; an agent reads it at every step. So the goal and the success criterion matter more than a step-by-step script, constraints matter more than a list of capabilities, and a stop condition is a required part of the prompt. Without one, the cost of a mistake grows with every extra loop.