A system prompt looks small, but in an AI workflow it behaves like the first configuration file loaded at runtime. It tells the model what role it has, what rules matter, what output shape to follow, and how to handle uncertainty. When that file is vague, the agent becomes vague too.
I used to think of prompts as clever wording. Now I think of them more like interface contracts. A good system prompt does not try to sound impressive. It removes ambiguity. It says what the agent should optimize for, what it should avoid, what tools it can use, and what a valid answer looks like.
What belongs in a system prompt
- The job: what the agent is responsible for and what it is not responsible for.
- The rules: business constraints, safety boundaries, tone, and escalation cases.
- The output contract: JSON fields, markdown sections, or exact response structure.
- The tool policy: when to call tools, when not to, and how to handle tool errors.
- The uncertainty policy: what to do when information is missing or conflicting.
The output contract is where many workflows become more stable. If the next step expects JSON, the prompt should describe the schema and the app should validate it. If the assistant is writing an email draft, the prompt should define tone, length, and required fields. Otherwise the model may produce something nice to read but hard to automate.
Keep it boring enough to maintain
The most useful system prompts I have seen are not poetic. They are boring in the best way. They use clear headings, short rules, and examples only where examples reduce confusion. They also change slowly. If every feature adds another paragraph to the same prompt, the file becomes a junk drawer and the agent starts inheriting contradictions.
A good test is simple: can another person read the system prompt and predict how the agent should behave in common edge cases? If not, the model probably cannot either.
