A Four-Part Framework for AI Prompts

While building an in-product AI assistant, I went down the prompt engineering rabbit hole. Elaborate role-playing scenarios, complex formatting tricks, instructions so detailed they could pass as legal contracts. Our prompt grew to 2,000 words with nested bullet points three levels deep.

The result: the same errors kept happening. Complexity wasn’t solving the fundamental issues.

After stripping it back to first principles, a simple four-part structure emerged that worked better than everything we’d tried before:

1. Context about role and environment
2. Tools and when to use them
3. Common mistakes to avoid
4. General guidelines and boundaries

That’s the entire framework. Here’s how each part works.

Part 1: Context and Role

Orient the AI to its environment and purpose. Answer: What platform is this? Who uses it? What’s the assistant’s role? What problems should it help with?

What makes this effective:

Factual, not fictional. Don’t ask the AI to “imagine” it’s something. State reality: “You are the X Assistant, designed to help users do Y.” No elaborate personas.

Relevant, not comprehensive. Don’t explain every feature. Focus on what’s relevant to the assistant’s function.

Scope boundaries. By stating what the assistant helps with, you implicitly define what’s outside scope.

Keep this section short—a paragraph of context, 3-4 sentences on supported use cases. Too much detail here is counterproductive. Domain knowledge belongs in tools or a knowledge base, not the system prompt.

Part 2: Tools and When to Use Them

Most approaches either list tools without context or bury usage guidelines in complex instructions. The key distinction:

• Tool definition: What it does (functionality)
• System prompt: When to use it (contextual guidance)

Example tool definition:

Receives resource data as csv file. The output of this tool is the filepath and the csv header.

Same tool in the system prompt:

- Use when a user asks about a specific resource to find its ID
- Use to help users find available resources matching certain criteria
- Use to verify if a resource exists before attempting operations on it

The first explains functionality. The second ties it to user scenarios.

Without this contextual guidance, the assistant often chose inappropriate tools or failed to use tools when helpful. For example, when asked “Can I book the conference room next Tuesday?”, the assistant would try to create a booking without first checking availability—a clear case for GetResourceData followed by GetAvailability.

Adding contextual usage guidance dramatically improved tool selection. Describe tools not just by what they do, but by the user needs they address.

Part 3: Common Mistakes to Avoid

A straightforward list of behaviors you’ve observed the assistant doing wrong. Format:

- DON'T [specific behavior]. INSTEAD [correct approach].

Examples:

- DON'T create a booking without checking availability. INSTEAD, use GetAvailability first.
- DON'T provide generic responses to error reports. INSTEAD, ask for specific error messages.
- DON'T guess resource IDs or permissions. INSTEAD, use lookup tools to verify.

Why this works:

• Direct. No ambiguity in “DON’T do X.”
• Specific. Each item addresses observed behavior, not hypotheticals.
• Actionable. Pairing “don’t” with “instead” redirects toward correct approaches.

Issues we struggled to fix through complex prompt adjustments disappeared when explicitly called out in this format. The assistant was guessing at information it didn’t have—we added “DON’T guess how features work, always check the help center first” and the problem vanished.

This section grows organically from real usage. Start with 3-4 items addressing the most pressing issues. Ours has grown to about ten.

Part 4: Guidelines and Boundaries

How the assistant should behave across all interactions: tone, boundaries, handling limitations.

- Address users formally
- When uncertain, state limitations rather than guessing
- If a request falls outside capabilities, explain and offer to connect with support
- Focus on helpful and accurate over verbose

The critical element: how to handle limitations. Every AI has boundaries. Without explicit guidance, assistants make up answers or overstep their role.

Example: our assistant receives questions about municipal regulations that vary by location and change over time. Rather than guess (and provide potentially incorrect information), guidelines instruct it to acknowledge when a question requires specialized knowledge and suggest appropriate resources.

This section doesn’t need to be long—5-6 bullet points covering core principles for behavior across all scenarios.

Why This Works

Separation of concerns. Each section addresses one aspect: context, capabilities, pitfalls, behavior. Adding a new tool only touches the tools section. A new mistake only touches the mistakes section.

Practical over theoretical. The “common mistakes” section evolves from observed failures, not hypothetical edge cases.

Maintainable. Clear structure makes it obvious where new information belongs.

Results after implementing this:

• 30% more user requests completed without human intervention
• 60% reduction in incorrect information
• 25% increase in user satisfaction

The simplicity also makes the prompt accessible to the whole team. Customer support notices a problem? They can suggest a specific addition to the mistakes section without needing to understand “prompt engineering.”

The Takeaway

Effective prompting isn’t about complexity—it’s about clarity and structure. Four sections: context, tools, mistakes, guidelines. Update based on observed failures. Keep each section focused on its specific purpose.

The best prompt isn’t the one that anticipates every scenario. It’s the one that provides clear guidance and evolves easily as needs change.