Most system prompts look great in the playground. They fall apart at 3am when the cron job fires and the agent is operating alone.
One engineer ran production agents for 35 days straight. Not demos. Actual autonomous jobs hitting APIs, writing to databases, running on schedule. His finding: most of what we put in system prompts is behavioral theater that doesn’t survive contact with a full context window. The agent looks disciplined in a short test session. Give it a long autonomous run with 40 tool calls deep into a pipeline, and those carefully worded instructions quietly lose their grip.
Here’s what he learned, and what you can do with it.
Two Types of Instructions
Behavioral instructions tell the agent how to act: “be concise,” “think step by step,” “be careful about data loss.” They feel useful in the playground. In production, they’re not. As the context window fills during a long autonomous run, these instructions are the first to lose influence. The agent has no mechanism to enforce them. They’re just tokens taking up space, and the model has no way to flag when it’s drifting from them.
State-based checks tell the agent what to verify against the real world before taking action. These hold.
“Before calling write_to_db: verify the record ID exists. If not, stop and write error to /tmp/errors.log.”
That instruction references external state. It’s testable. It either passes or it doesn’t. There’s no ambiguity, no interpretation drift, no room for the agent to quietly rationalize skipping it. Compare that to “be careful about data loss,” which means something different in every context and nothing specific in any of them. State-based checks survive context pressure in a way behavioral instructions simply don’t.
What to Cut From Your System Prompt
- Tone instructions (“be concise,” “be helpful”): no enforcement mechanism exists, just token waste
- Meta-process instructions (“think step by step”): helpful in interactive chat, adds noise in autonomous runs where the model isn’t pausing to reflect between tool calls
- Personality framing (“you are an expert at X”): sounds credible in the playground, means nothing at runtime when the agent is 30 steps into a pipeline
- Vague constraints (“don’t make mistakes,” “be careful about data loss”): an agent cannot act on warnings this abstract, and it has no way to surface when they’re being violated
These aren’t bad instructions in every context. They’re instructions for a different context: interactive chat, where the model can ask clarifying questions and the user is right there. Scheduled autonomous agents are a different environment entirely. The agent can’t pause, can’t ask, and no one is watching the output in real time. Vague guidance is worse than no guidance because it creates the illusion of safety.
✅ What Survives Production
- Numbered constraints with verifiable conditions: “Before calling write_to_db, confirm the record ID exists in the response.”
- Explicit failure states with exact paths: “If this call returns anything other than HTTP 200, stop. Write the exact error to /tmp/errors.log. Do not retry. Do not proceed.”
- File paths and tool names written out directly, not descriptions of them. “Write to /tmp/errors.log” survives. “Write to the appropriate error location” does not.
- A one-line scope anchor: “You are managing the content pipeline for 2026-04-26. Your working directory is [path].” Date, directory, role. Nothing else.
- Ordered decision trees for branching logic: “If A, do X. If B, do Y. If neither, stop and log.” Agents handle explicit branching far better than implied judgment calls.
How to Rewrite Your Prompts
- Open your current system prompt and highlight every instruction that describes how the agent should feel, think, or approach its work.
- For each highlighted instruction, ask: “What external state would confirm this was followed?” If you can’t answer it concretely, cut it. “Be concise” has no external state. “Response must be under 200 tokens” does.
- Replace behavioral instructions with state checks. “Be careful with data” becomes “Before any write operation, fetch the current record and compare field by field. If any field has changed since the last read, stop and log the diff to /tmp/conflicts.log.”
- Add explicit failure states to every critical operation. Define what to check, what counts as failure, exactly where to write the error, and whether to retry or stop immediately. Leaving any of these undefined means the agent will improvise, and improvisation at 3am is how you lose data.
- Add a one-line scope anchor at the top. Date, working directory, role in the pipeline. No personality framing. Just concrete context that orients the agent before the first tool call fires.
The Core Insight
“Think step by step” is an instruction to a behavior. “Before writing to Supabase, fetch the current record and compare” is a check against state.
One holds when the context window fills. The other fades and takes your data integrity with it. The difference isn’t subtle once you’ve watched a well-intentioned behavioral prompt get quietly overridden by a long context window at the worst possible moment.
Pull up your production agent prompts this week. Not the demo ones, the ones actually running on cron. If they’re packed with behavioral instructions, they’re running on hope. State-based checks are the only thing that reliably holds when no one is watching.
That’s the prompt pattern worth copying to every agent you build!
Frequently Asked Questions
Q: Should I add an “output contract” block to my prompts?
Yes, if you’re running autonomous agents that need reliable downstream parsing. Define exact field names, data types, and what to do if a value is missing. One practitioner also uses a short “do not do” list with specific examples (not just rules), which seems to stick better than positive examples in longer chains.
Q: Does my choice of model affect how I should write prompts?
Absolutely. Prompting advice without specifying the model is incomplete, Claude 4.7 and GPT-4o respond differently to the same instructions. For example, “think step by step” was critical for older GPT models but is now baked into Claude’s post-training, so it can cause overthinking. Also check whether you’re replacing the base system prompt or layering on top, adding personality framing to Claude Code (which already has “you’re a software engineer”) has less impact than replacing the system prompt entirely.
Q: When do behavioral instructions conflict with my agent’s goals?
When they compete. “Never use globals” works fine until a task is 100x easier using them, the agent picks the path of least resistance. This doesn’t mean behavioral instructions are useless; they work well when multiple options are roughly equivalent. The key: don’t fill context until instructions are ignored. Instead, run tightly-focused loops that handle one thing at a time, using prompt caching to control costs.
Q: What’s the difference between “be specific” and “include [client name], [service], and one CTA”?
The first is behavioral noise that dies in long conversations. The second anchors to concrete, verifiable outputs, it’s a state-based check disguised as an instruction. The [bracket] pattern is lightweight but powerful: it turns vague guidance into something you can actually verify and test downstream.
The system prompt pattern I keep rewriting — and the one I’ve copied to every agent
by u/Most-Agent-7566 in PromptEngineering