Bri's Production Prompt Engineering Method

Last updated: 7 August 2026

Eliminate inconsistent AI agent behavior by applying a systematic set of prompt design rules and audit practices that produce repeatable, predictable outputs in production.

// TL;DR

Bri's Production Prompt Engineering Method is a systematic set of rules and audit practices for making AI agents produce consistent, predictable outputs in production. It replaces prohibitive language ('never,' 'avoid') with calm decision criteria, declares exact output shapes, moves dynamic data and deterministic work out of the prompt, and audits accumulated patches for conflicts. Use it whenever an agent behaves inconsistently or wrongly, when preparing a model upgrade, when onboarding a new agent workflow, or when auditing a prompt that has collected patches over time. The core discipline: set up eval tests first, then clean up before adding anything new.

Framework

// When should you use Bri's Production Prompt Engineering Method?

Use this skill whenever an AI agent is producing inconsistent, unpredictable, or wrong outputs, or when preparing to upgrade a model, onboard a new agent workflow, or audit an existing prompt that has accumulated patches over time.

// What do you need before applying this method?

current_promptrequired
The full text of the prompt(s) currently being sent to the LLM, including any system instructions and role definitions.
agent_purposerequired
A plain-English description of what this agent is supposed to do and what a correct output looks like.
eval_failures
Description of the failure mode(s) observed — what the agent is doing wrong, inconsistently, or refusing to do.
patch_history
A log or list of any instructions that have been added to the prompt over time to fix specific bugs or behaviors.

// What are the core principles behind production prompt engineering?

Decision Criteria Over Prohibitions

Never tell an agent what NOT to do without telling it what to do instead. Strong prohibitive words like 'never,' 'avoid,' and 'don't' signal urgency and importance, which causes the agent to over-prioritize the restriction and fill in wrong behavior. Replace every prohibition with calm decision criteria that explain when to act, when to hold back, and why.

Cleanup First

When something goes wrong, the instinct is to add a new instruction — but patches accumulate and eventually contradict each other. Always attempt to clean up and simplify the existing prompt before adding anything new. Lean prompts produce more consistent outputs than heavily patched ones.

Declare Exact Output

Always specify exactly how the agent should respond — format, length, and structure — using a dedicated output section (e.g., a reply tag). Models follow declared output shapes faithfully and produce repeatable responses as a result.

No Hard-Coded Dynamic Data

Anything that changes from run to run — record IDs, account details, live pricing — must never be hard-coded into the prompt. It should be injected at runtime by the harness as a variable. Static prompts should contain only stable instructions.

Balanced Trade-Off Framing

When an agent must make a judgment call, state the cost of both choices — not just one side. Informing the agent only of the cost of one option causes it to consistently error in that direction, becoming either too aggressive or too conservative.

Move Deterministic Work Outside the Prompt

Never ask an agent to calculate, compute, or generate something deterministic by hand inside the prompt. Offload that work to a tool or directly into the harness code, then pass the result back into the agent.

Eval-Before-Iterate Discipline

Before making any prompt changes, set up eval tests that make real-time model calls so you can observe output changes as you modify the prompt. Iterating without evals is guessing.

// How do you apply Bri's method step by step?

1
Set up an eval test suite before touching the prompt
Create a test that makes real API calls with the current prompt against representative inputs. Record what passes and what fails. This baseline is your reference point for every change you make. Do not skip this step — iterating without evals means you cannot verify improvement.
2
Audit the prompt for prohibitive language
Scan every instruction for the words 'never,' 'avoid,' 'don't,' 'critical,' or any phrasing that tells the agent to NOT do something. Flag every instance. These are your primary suspects for over-caution failures and wrong-direction behavior.
3
Replace each prohibition with decision criteria
For each flagged prohibition, rewrite it as a calm, positive decision rule: 'When condition X is true, do Y. When condition Z is true, do W.' Remove urgency language entirely. The agent should be able to evaluate the criteria neutrally without strong-word signals overriding its judgment.
4
Reformat the prompt with HTML tags and strip extraneous content
Structure the prompt using HTML-style tags to clearly separate sections (e.g., <role>, <instructions>, <reply>). Remove anything the model already knows by default. Cut all filler, redundant explanations, and anything not strictly necessary. Shorter and cleaner consistently outperforms longer and more detailed.
5
Move all dynamic data out of the prompt body
Identify any values that change between runs — account IDs, user details, live records, pricing. Remove them from the static prompt and replace with runtime-injected variables handled by the harness. The prompt itself should never need to change just because the data changed.
6
Declare the exact expected output in a reply tag
Add an explicit output declaration section (e.g., a <reply> tag) that specifies the format, length, and structure of the agent's response. If you need a one-to-two sentence answer, say so explicitly. The agent will follow a declared output shape faithfully.
7
Check for one-sided trade-off framing in any judgment-call instructions
For every instruction where the agent must weigh two options, verify that the prompt states the cost of BOTH choices — not just the cost of one. If only one side is represented, the agent will consistently drift toward avoiding that cost, becoming either too aggressive or too conservative.
8
Offload any deterministic computation to tools or harness code
If the prompt asks the agent to calculate, look up, or generate any value that has a single correct answer, remove that responsibility from the prompt entirely. Implement it as a tool call or compute it in the harness and inject the result. Asking an LLM to do deterministic work by hand produces inconsistent outputs.
9
Run a patch audit if the prompt has accumulated fixes over time
For each patch instruction in the prompt, ask: (a) Is this still relevant? (b) Does it conflict with any other instruction? (c) Can I name the specific failure it prevents? If you cannot name the specific failure, it should be the first thing cut. Flag all 'always' and 'never' instructions for this test. Conflicting instruction pairs must be resolved — keep one, remove or merge the other — because the model will try to enforce all of them and no one can predict which wins.
10
Re-run the eval suite and verify consistent output
After all changes, run the eval tests multiple times (since model calls vary). Look for a short, clear, definitive answer that matches your declared output shape consistently across runs. If it still fails, return to step 2 — do not add new instructions until cleanup possibilities are exhausted.

// What does this method look like in real agent scenarios?

A customer support agent is supposed to automatically escalate billing disputes to a human agent, but instead tries to resolve them itself.

Audit the prompt for prohibitive language. The failure is caused by a strong defensive instruction like 'avoid escalating unless absolutely necessary,' which overrides the escalation rule even when it is explicitly stated. Remove the avoidance instruction entirely and replace it with decision criteria: 'Escalate when the issue is a billing dispute. Continue resolving when the issue is a general product question.' The agent can now evaluate calmly without strong-word signals distorting its decision.

An agent answering account questions gives verbose, inconsistent answers — sometimes correct, sometimes wrong — when a user asks a simple factual question about their plan.

The prompt likely has too much extraneous detail, lacks HTML tag formatting, and has no declared output shape. Reformat with HTML tags to separate instruction sections. Strip any content the model knows by default. Add a <reply> tag specifying 'Respond in one to two sentences with a direct, factual answer.' Remove any hard-coded account data and replace with runtime-injected variables. Run evals — the output should become short, consistent, and definitive.

A long-running agent has had eight patches added to it over several months and has started producing unpredictable behavior.

Run a patch audit. For each patch: check if it is still relevant (was the underlying bug fixed?), check if it conflicts with any other instruction, and check if you can name the specific failure it prevents. Flag all 'always' and 'never' instructions. Identify conflicting pairs and resolve them. Remove stale instructions whose root cause no longer exists. Do not add new instructions until the audit is complete and conflicts are resolved.

// What mistakes should you avoid when engineering production prompts?

Using prohibitive words — 'never,' 'avoid,' 'don't,' 'critical' — without stating what the agent should do instead. Wrong behavior fills in wherever a gap is left.
Adding a new patch instruction every time something breaks, without ever cleaning up the prompt. Patches accumulate, contradict each other, and the model tries to enforce all of them.
Hard-coding dynamic data (record IDs, account details, live pricing) directly into the prompt instead of injecting it at runtime via the harness.
Failing to declare the exact expected output format, length, and structure. Without a declared shape, output length and style drift run to run.
Asking the agent to perform deterministic computation (calculations, lookups) inside the prompt instead of offloading to a tool or harness code.
Framing a judgment call by stating only the cost of one option. The agent will consistently drift toward avoiding that single stated cost.
Iterating on prompt design without eval tests in place, making it impossible to verify whether a change improved or worsened behavior.
Keeping 'always' or 'never' instructions in the prompt without being able to name the specific failure each one prevents. The model enforces them faithfully whether they are still needed or not.
Assuming that a prompt that worked on an older model will continue to work after a model upgrade. Newer models follow instructions more literally and will abstain rather than guess, breaking prompt patterns that older models glossed over.

// What key terms should you know for production prompt engineering?

Decision Criteria: A calm, positive instruction that tells the agent when to take one action versus another, and why — used as the correct replacement for any prohibitive instruction. Removes urgency signaling and allows the model to evaluate neutrally.
Patch: An instruction added to a prompt after the fact to fix a specific observed bug or behavior. Patches are necessary but must be documented, audited for conflicts, and removed when their root cause is resolved.
Patch Audit: A systematic review of every patch in a prompt that checks: whether the patch is still relevant, whether it conflicts with any other instruction, and whether you can name the specific failure it prevents. Run before any model upgrade.
Stale Instruction: A patch instruction whose original root cause (e.g., a data pipeline bug) has been fixed, but whose instruction was never removed from the prompt. The model still enforces it faithfully despite it no longer being necessary.
Conflicting Instructions: Two or more instructions in the same prompt that direct the agent toward incompatible behaviors. The model attempts to enforce all of them, producing unpredictable outputs because no one can predict which instruction wins in any given run.
Harness: The code layer that wraps and manages the agent — responsible for injecting dynamic runtime data into the prompt as variables, calling tools, and passing computed results back to the model. The harness handles everything that should not live inside the static prompt.
Eval Set: A test suite of representative inputs that makes real-time model calls and checks outputs against defined criteria (e.g., correct decision made, correct response length). Must be set up before iterating on prompt design.
Reply Tag: An HTML-style tag (e.g., <reply>) placed in the prompt to declare the exact expected format, length, and structure of the agent's output. Produces repeatable, consistently shaped responses.
Over-Caution: A failure pattern where the model refuses to do something it is clearly equipped to do, caused by defensive instructions that the agent treats as top priority rather than as guardrails.
One-Sided Trade-Off: A failure pattern where the model consistently errors in one direction (too aggressive or too conservative) because the prompt states the cost of only one side of a judgment call, leaving the agent unable to weigh both options.
Cleanup First: The prompt iteration discipline of always attempting to simplify and remove instructions before adding new ones, to prevent patch accumulation and conflicting instructions.

// FREQUENTLY ASKED QUESTIONS

What is Bri's Production Prompt Engineering Method?

It's a systematic set of rules for making AI agents behave consistently in production. The method replaces prohibitive language with decision criteria, declares exact output shapes, moves dynamic data and deterministic calculations out of the prompt, frames trade-offs from both sides, and audits accumulated patches for conflicts — all validated with eval tests set up before you iterate.

Why do prohibitive words like 'never' and 'avoid' break AI agents?

Strong prohibitive words signal urgency and importance, causing the agent to over-prioritize the restriction and fill in wrong behavior wherever a gap exists. The fix is to replace every prohibition with calm decision criteria: state when to act, when to hold back, and why. This lets the model evaluate neutrally instead of being distorted by strong-word signals.

How do I fix an AI agent that gives inconsistent outputs?

Set up eval tests that make real API calls, then audit the prompt for prohibitive language, reformat it with HTML tags, strip filler, and add an explicit output declaration (a reply tag) specifying format and length. Remove hard-coded dynamic data and move deterministic work to tools. Re-run evals across multiple runs to verify consistency before adding any new instruction.

How do I clean up a prompt that has too many patches?

Run a patch audit. For each patch, ask three questions: is it still relevant, does it conflict with another instruction, and can you name the specific failure it prevents? If you can't name the failure, cut it first. Flag all 'always' and 'never' instructions, resolve conflicting pairs by keeping one, and remove stale instructions whose root cause is already fixed.

How does this method compare to just adding more instructions when something breaks?

Adding instructions is the default instinct, but patches accumulate, contradict each other, and force the model to enforce all of them unpredictably. Bri's method uses Cleanup First: always simplify and remove before adding. Lean prompts consistently outperform heavily patched ones, and eval tests prove whether a change actually improved behavior rather than guessing.

When should I use this prompt engineering method?

Use it whenever an AI agent produces inconsistent, unpredictable, or wrong outputs, when preparing to upgrade a model, when onboarding a new agent workflow, or when auditing a prompt that has accumulated patches over time. Model upgrades are a critical trigger — newer models follow instructions more literally and break patterns older models glossed over.

What results can I expect after applying this method?

Expect short, clear, definitive outputs that match your declared shape consistently across multiple runs. Over-caution failures disappear once prohibitions become decision criteria, one-sided drift stops once trade-offs are balanced, and deterministic errors vanish once calculations move to tools. Because you validate with evals, you can measure the improvement rather than assume it.

What is a patch audit and when do I run one?

A patch audit is a systematic review of every after-the-fact instruction in a prompt, checking whether each is still relevant, whether it conflicts with others, and whether you can name the specific failure it prevents. Run it whenever a prompt has accumulated fixes over time and especially before any model upgrade, since newer models enforce stale instructions more literally.

Why shouldn't I hard-code account IDs or pricing into a prompt?

Anything that changes from run to run — record IDs, account details, live pricing — must be injected at runtime by the harness as a variable, not baked into the static prompt. Hard-coding dynamic data forces you to rewrite the prompt every time data changes and produces stale, wrong outputs. Static prompts should contain only stable instructions.

Should an AI agent do calculations inside the prompt?

No — never ask an agent to calculate, compute, or generate anything deterministic by hand inside the prompt. Offload that work to a tool call or compute it in the harness code, then pass the result back to the model. Asking an LLM to do deterministic work by hand produces inconsistent outputs across runs.

What is a reply tag in prompt engineering?

A reply tag is an HTML-style tag (e.g., <reply>) placed in the prompt to declare the exact expected format, length, and structure of the agent's output. Models follow declared output shapes faithfully, so a reply tag saying 'respond in one to two sentences with a direct, factual answer' produces repeatable, consistently shaped responses across runs.

Why does my agent keep being too cautious or too aggressive?

This is usually a one-sided trade-off problem. When a judgment-call instruction states the cost of only one option, the agent consistently drifts toward avoiding that single stated cost. The fix is balanced trade-off framing: state the cost of both choices so the agent can weigh them, rather than reflexively erroring in one direction.

// GET THIS SKILL — FREE