How to Write a System Prompt That Actually Works

90% of system prompts fail because they're either too vague or too rigid. Here's the framework we use to make AI agents that work reliably — every single day.

You copy a system prompt template from Twitter. You paste it into ChatGPT. The first response looks amazing. By response five, the AI has forgotten half of what you told it.

Sound familiar?

The problem isn't the model. It's how you're writing your prompt. After running 4 production AI agents for over a year — agents that handle research, operations, content, and monitoring — I've learned that prompt engineering is 80% structure and 20% words.

Here's everything I know about writing system prompts that actually stick.

1. Start With Identity, Not Instructions

The biggest mistake in system prompts? Starting with what the AI should do.

Instead, start with who the AI is.

You are a helpful assistant that
helps with customer support.
Answer questions about our product.
Be professional and friendly.

You are Maya — a senior support
engineer at Acme. You've been with
the team 3 years. You know the
product inside out and you don't
BS customers with template answers.
You fix problems.

Why does identity work? Because LLMs are excellent at being someone. When you give them a character with depth, every response flows naturally from that character. You don't need 50 rules when the identity implies them.

2. Separate The Three Layers

Every good system prompt has three distinct layers. Mix them up and you get mush.

Layer 1: Soul (Who)

Personality, tone, values, boundaries. This is the character. It rarely changes.

Layer 2: Rules (How)

Operational instructions, workflows, constraints, tools. This is the playbook. It evolves as you learn what works.

Layer 3: Context (For Whom)

Information about the user, the environment, current state. This is the situation. It changes per conversation.

# SOUL — Who you are
You are Bolt, a fast and focused work assistant.
You don't waste words. You execute.

# RULES — How you operate
- Always check calendar before scheduling
- Draft emails, never send without approval
- Use bullet points for updates

# CONTEXT — The situation
User: Johnny, CEO of a truck consulting company.
Timezone: Europe/Amsterdam.
Current project: Zero-emission truck database.

This separation is the core idea behind the 3-File Framework — but the principle applies even if you're just using ChatGPT's custom instructions.

3. Use Constraints, Not Suggestions

Vague instructions get vague results. The model isn't being lazy — it's being compliant with ambiguity.

Try to keep responses concise.
It would be good to include
sources when possible.

Max 3 paragraphs per response.
Every claim must include a source
URL. No exceptions.

Words like "try to," "when possible," and "it would be good to" are permission to ignore the instruction. Replace them with clear rules.

4. Show, Don't Tell

Examples are worth 100x their weight in instructions. Instead of describing the format you want, show it.

# When reporting a completed task:

## ✅ Task Complete: [Name]
**What:** [one-line summary]
**Result:** [outcome or link]
**Time:** [duration]
**Next:** [follow-up if any]

# Example:
## ✅ Task Complete: Blog Post Draft
**What:** Wrote "5 Signs Your Agent Is Just a Chatbot"
**Result:** 1,200 words, ready for review
**Time:** 25 minutes
**Next:** Add meta tags and publish

One example replaces an entire paragraph of explanation. The model pattern-matches instantly.

5. Build In Memory Hooks

System prompts are static. Conversations are dynamic. The gap between them is where agents break down.

The solution? Give your agent explicit instructions for what to remember and where to store it.

# Memory Protocol
After every task, log to memory/daily-notes.md:
- What was done
- What was decided
- What's pending

Before starting work, read today's notes.
If uncertain about a past decision, search memory first.

This transforms a stateless prompt into a stateful agent. The agent builds its own context over time, reducing the load on your system prompt.

6. Define the Edges

Every good system prompt answers: what should the agent NOT do?

Without boundaries, agents wander. They try to be helpful by doing things you never asked for. Define the fence.

# Boundaries
NEVER:
- Send emails without explicit approval
- Delete files or data
- Make financial commitments
- Share internal documents externally

ALWAYS ask before:
- Any external communication
- Purchases over €10
- Changes to production systems

The "never" list is more important than the "always" list. It's easier to expand permissions later than to undo damage.

7. Write for Maintenance, Not Perfection

Your first system prompt will be wrong. That's fine. What matters is how easy it is to fix.

• Use headers and sections. When something breaks, you need to find and fix the relevant rule fast.
• Date your changes. Add a comment when you modify a rule so you know why it's there.
• Keep a "lessons learned" section. When the agent fails, document what happened and the fix. This becomes your most valuable section.
• Version it. Put your prompt in a file, track changes, revert when things go wrong.

# Lessons Learned
- 2025-01-15: Agent was sending duplicate emails.
  Fix: Added "check sent folder before sending" rule.
- 2025-02-03: Agent forgot timezone.
  Fix: Added timezone to context, not just rules.

8. The Prompt Anatomy Checklist

Before you ship a system prompt, run through this checklist:

• Does it have a clear identity (name, role, personality)?
• Are soul/rules/context separated?
• Are constraints specific (no "try to" or "when possible")?
• Does it include at least one output example?
• Are boundaries defined (what NOT to do)?
• Is there a memory/logging protocol?
• Is it organized with headers for easy maintenance?
• Has it been tested with 10+ real conversations?

If you check all 8, you're in the top 5% of system prompts out there. Seriously.

The Bottom Line

System prompts aren't magic spells. They're job descriptions for a very capable but very literal employee. Write them like you'd onboard a real person: tell them who they are, how to work, what matters, and what to never touch.

Start simple. Ship it. Watch it break. Fix the break. Repeat.

That's how you build agents that actually work.