System PromptsPrompt EngineeringAI Agents

Writing System Prompts That Actually Hold Up in Production

Most system prompts work in testing and fall apart in production. Here's how I write prompts that stay reliable across thousands of real runs.

H
Hichem Refes ·
Writing System Prompts That Actually Hold Up in Production

A system prompt that works on your first ten test runs will still fail on run four hundred. I learned this the expensive way, watching an agent that had performed flawlessly for a week suddenly start skipping a step nobody had ever seen it skip.

The problem was not the model. The problem was a prompt written for the demo, not for production.

Why Demo Prompts Break

Most system prompts get written the same way. You describe the task, add a few examples, test it a handful of times, and ship it once the output looks right. This works until the input varies even slightly from what you tested.

I write prompts for roughly 50 agents now, and the pattern is always the same. The prompt breaks on the edge case nobody thought to test: the email with no subject line, the client name with an apostrophe, the transcript that cuts off mid-sentence. Demo prompts are optimized for the happy path. Production prompts have to survive everything else.

AI Agent Blueprint — futuristic system architecture diagram
Free Resource

Want the blueprint behind this system?

The exact architecture, memory layers, and delegation patterns I use to run 50 agents across two businesses.

Get the AI Agent Blueprint →

The Structure That Holds Up

Role and boundary first, always. Every prompt I write starts with what the agent is and, just as important, what it is not allowed to do. “You draft replies to client emails. You never send an email without human approval. You never make commitments about pricing or timelines.” The boundary line prevents scope creep inside the model’s reasoning, not just in the surrounding code.

Explicit failure instructions, not just success instructions. Most prompts tell the model what to do when things go well. They skip what to do when the input is incomplete, contradictory, or missing entirely. I now write a dedicated section for this in every prompt: “If the input is missing required information, do not guess. Return status: incomplete and list what is missing.” Without this, the model fills gaps with plausible-sounding invention, and plausible invention is the hardest kind of error to catch.

Format contracts, not format suggestions. “Respond in a helpful format” produces inconsistent output. “Respond with exactly these five fields, in this order, using this JSON schema” produces output your downstream code can actually parse. I lost a full day once to an agent that alternated between a bulleted list and a paragraph depending on mood, because the prompt asked for a “clear summary” instead of a defined structure.

Few-shot examples that include the edge cases. Most people put their best example first. I put a messy one first. If the model sees a clean example before anything else, it anchors to clean inputs and struggles when reality shows up. Lead with the input that looks like Tuesday afternoon, not the one that looks like a screenshot from a keynote.

The Test That Actually Predicts Production Behavior

Ayla assembles a modular system prompt from labeled blocks floating in a holographic workspace, each block locking into place
Ayla assembles a modular system prompt from labeled blocks floating in a holographic workspace, each block locking into place

Testing a prompt against ten curated inputs tells you almost nothing. I run every new prompt against a batch of real, unfiltered historical inputs pulled straight from logs. Not the cleaned-up ones. The actual raw data, including the malformed entries, the outliers, and the ones that made no sense even to me.

If the prompt handles that batch without a human needing to intervene, it is ready. If it needs babysitting on the historical data, it will need babysitting in production, just later and more expensively.

Version Every Prompt Like Code

I keep every system prompt in version control with a changelog, the same as any other piece of production logic. When output quality drifts, the first question is always “what changed in the prompt,” and I need to answer that in seconds, not by trying to remember.

This also means I never edit a live prompt directly. I duplicate it, test the new version against the same historical batch, compare outputs side by side, and only then promote it. A prompt change that looks like an improvement in three examples can quietly regress on the fortieth.

The Real Lesson

A good system prompt is not a clever piece of writing. It is a specification. The clearer the boundaries, the more explicit the failure paths, and the more honest the test data, the longer that prompt survives contact with real users doing things you did not anticipate.

Write for the input you have not seen yet. That is the one that will show up first.

The newsletter covers the exact prompt templates and testing batches I use across Ayla OS agents.

Subscribe to the newsletter