The "enhance prompt" button — you know, the one in every image generator and half the chat interfaces now — has this quiet tension baked into it that most people never stop to examine. Is it actually making things better, or is it quietly rewriting your intent into something the model finds easier to handle? Daniel sent us a question that goes straight at this, and he's not asking about the consumer version. He wants to know how you build a prompt enhancer as a preprocessing layer in an agentic pipeline, where the stakes are completely different. A hallucinated detail in the enhancer becomes ground truth for every downstream tool. His two big worries: content loss — the enhancer drops a constraint you actually cared about — and content invention, where it hallucinates specifics you never asked for and launders them into the pipeline as if they were your intent. So the real question is, how do you write the prompt for the prompt enhancer? What does a well-constructed one look like, and when should you not use one at all?
And this is a prompt-writing question at its core, which is what makes it so interesting. You're using one model to rewrite input for another model, and the thing doing the rewriting is itself being prompted. So every failure mode of prompt engineering applies recursively. If your enhancer prompt is vague, the enhancer's output will be... If it's over-constrained, the enhancer might not actually improve anything. And the two failure pattern Daniel named — content loss and content invention — those aren't separate problems, really. They're both symptoms of the same thing: the enhancer doesn't know what matters.
Right. It's guessing.
It's guessing. And in a consumer tool, guessing is fine — the user sees the enhanced prompt and can say "no, that's not what I meant." But in an agentic pipeline, there's no human in the loop. The enhancer rewrites, the agent acts, and the user might never even see what the enhancer produced. That's the laundering problem Daniel's worried about.
So let's scope this properly. We're not talking about the "make this prompt better" button in Midjourney or DALL-E, where you get to review the rewrite. We're talking about a dedicated LLM call that sits between the user and the rest of the system — the preprocessor layer. User types something raw, the enhancer rewrites it, and the enhanced version is what gets fed to the main model or the tool chain. The user never sees the enhanced prompt, and the downstream components don't know it was enhanced. They treat it as authoritative.
And that's the entire problem in one sentence. The downstream components treat it as authoritative. So if the enhancer adds "use PostgreSQL" when the user just said "database," every subsequent step assumes PostgreSQL is a requirement. The agent provisions a PostgreSQL instance, writes Postgres-specific queries, configures backups for Postgres — and the user is sitting there wondering why their MySQL-compatible hosting bill just arrived.
That's content invention. What about content loss?
Content loss is sneakier because you often don't notice it until something breaks. Imagine a user says "I need a Python script that runs on Windows without admin rights, and it must use only the standard library." A naive enhancer might rewrite that as "Create a Python script using only standard libraries" — it kept "Python" and "standard library" but dropped "no admin rights" because that looked like an environmental detail rather than a hard constraint. The script gets written, it tries to install something system-wide, and it fails on the user's locked-down corporate machine. The user blames the agent. The agent never knew about the constraint because the enhancer ate it.
So the enhancer is an editor that doesn't know which words are load-bearing.
And most naive enhancer prompts actively incentivize the editor to be creative. The typical naive prompt says something like "Improve the following prompt by adding detail, clarifying intent, and making it more specific." That instruction — "adding detail" and "making it more specific" — that's an expansion directive with no guardrails. You're telling the model to invent.
"Add detail." Detail from where? It's not in the input.
Right. The model has to generate it. And models are very good at generating plausible-sounding detail that is completely fabricated. That's what they do. So the naive enhancer is basically a hallucination machine with a permission slip.
Which brings us to the core design tension. Daniel mentioned it in his question — distillation versus expansion. You can ask the enhancer to expand, which is where invention lives, or you can ask it to distill, which is about removing ambiguity and clarifying structure without adding new content. The practitioner wisdom, and what we're seeing in production systems, is that distillation produces more faithful results.
Because distillation constrains the output space. If you tell the model "reorganize this for clarity but do not add any requirements not explicitly stated in the input," you've drawn a boundary. The model can restructure, it can resolve genuine ambiguities — "when you say 'database,' do you mean the one we've been discussing or a new one?" — but it can't invent a database vendor. Expansion removes that boundary. Expansion says "make it better," and the model decides what "better" means.
And "better" usually means "more like the training data."
Yes. The model has seen millions of well-specified prompts in its training data — prompts that name specific tools, specific versions, specific approaches. So when you say "make this better," it pattern-matches toward that distribution. "Database" becomes "PostgreSQL" because that's what detailed prompts look like. "Write a function" becomes "Write a Python function with type hints and docstrings" because that's what good prompts specify. The model isn't being malicious — it's being statistically reasonable. But statistical reasonableness is not fidelity.
So let's get concrete. If someone's building a prompt enhancer for an agentic pipeline, what does a well-constructed system prompt actually look like? Walk me through it.
Okay. The first thing is explicit preservation rules. And I mean explicit — not "try to keep the user's intent," which is vague and unenforceable, but specific instructions like "If the user mentions a version number, file format, operating system, tool name, or numerical constraint, include it verbatim in the output." Verbatim. Not paraphrased, not "improved." The exact string the user typed.
Because "Python 3.11" and "Python 3.12" are different things, and the enhancer has no way to know which one matters.
The second rule is a hard negative constraint: "Do not add any requirement, constraint, tool, format, or specification that is not explicitly stated in the user's input." That's the anti-hallucination clause. It's not enough to say "be faithful" — you have to say "do not add." And the third piece, which is less obvious, is the "refuse to enhance" clause. If the user's input is already specific, unambiguous, and self-contained, the enhancer should return it unchanged. No rewriting, no "improving," no adding section headers. Just echo it back.
That last one is interesting because it runs counter to what most people assume an enhancer should do. The assumption is that the enhancer always makes things better. But if the input is already good, the enhancer can only make it worse.
That's the "do no harm" principle, and it's the one most production enhancers violate. They're configured to always produce output, always add something, because the developer thinks "well, I built this thing, it should do something." But an enhancer that never says "this is fine, leave it alone" is an enhancer that will eventually hallucinate on a perfectly good prompt.
So if a user says "Run the migration script at slash opt slash scripts slash migrate dot sh with the dash dash dry-run flag," a good enhancer returns that verbatim. A bad one adds "and also validate the schema first."
Which breaks the dry run, because dry run means "don't actually do anything." The enhancer just countermanded the user's explicit instruction by being helpful.
The helpfulness becomes interference.
That's the phrase. Helpfulness becomes interference. And it's especially dangerous when the user is an expert who knows exactly what they want. The enhancer is optimized for the vague, uncertain user — "I want a picture of a cat" becomes "A photorealistic orange tabby cat sitting on a windowsill, golden hour lighting, shallow depth of field." That's genuinely useful for image generation. But the expert who says "I need a Python 3.11 script using only asyncio, no third-party libraries, compatible with Windows" — that person doesn't need enhancement. They need the system to do exactly what they said.
So the enhancer's value is inversely proportional to the user's expertise.
And to the specificity of the input. Baidu's work on ERNIE-Image — their prompt enhancer for image generation — found exactly this pattern. The enhancer improved output quality for vague inputs but degraded it for specific ones. There's no reason to think text-based agentic workflows are different. The enhancer helps most when the user is uncertain or underspecified, and hurts when the user knows exactly what they want.
Which suggests the "refuse to enhance" clause isn't a nice-to-have. It's the thing that prevents your enhancer from being a net negative for your most competent users.
Right. And those are the users you least want to alienate, because they're the ones who will notice the enhancer screwed up and lose trust in the whole system.
Let's talk about structured output. Daniel mentioned it as a technique, and I know you've thought about this. Instead of asking the enhancer to produce free text, you ask it to produce a structured object — JSON with specific fields. Why does that help?
It helps because it forces the model to categorize rather than generate. When you ask for free text, the model is in generation mode — it's producing prose, and prose invites elaboration, connective tissue, "improvements." When you ask for a JSON object with fields like "user_constraints," "core_task," "environmental_requirements," and "verbatim_sections," you're asking the model to sort the user's input into buckets. Sorting is a lower-temperature operation than generating.
It's the difference between "rewrite this" and "extract these specific things from this."
And you can include fields that serve as guardrails. A "faithfulness_score" field where the model self-evaluates its confidence that nothing was lost or added. A "verbatim_sections" array that contains the exact text of any part of the user's input that was preserved word-for-word. A "clarifications_made" array that can only contain ambiguity resolutions — "the user said 'the database' and from context this refers to the production Postgres instance" — never new requirements.
The self-evaluated faithfulness score sounds circular. The model that might have hallucinated is also the model evaluating whether it hallucinated?
It's not perfect, but it's surprisingly useful as a signal. If the model assigns a low faithfulness score to its own output, something probably went wrong. And you can use that score downstream — if it's below a threshold, flag the output for human review or fall back to the original unenhanced prompt. It's a circuit breaker, not a guarantee.
That makes sense. The score doesn't need to be perfectly calibrated — it just needs to catch the obvious failures.
Right. And you can combine it with other validation techniques. Daniel mentioned diffing the before and after — that's a separate step where you compare the original input to the enhanced output and flag any additions that don't trace back to the original. This can be a second LLM call — "Here's the original and the enhanced version. List any requirements, constraints, or specifications in the enhanced version that are not present in the original" — or it can be a simpler rule-based check for verbatim substring preservation.
The second LLM call is interesting because it inverts the problem. Instead of asking one model to be faithful, you're asking a different model to catch unfaithfulness. The evaluator has an easier job than the enhancer — it's just doing comparison, not generation.
And it's harder to fool, because the evaluator sees both texts side by side. The enhancer might hallucinate "use PostgreSQL" and confidently assert a faithfulness score of 0.95. But the evaluator, looking at the original text that just says "database," can immediately flag the addition. You've created a check and balance.
This is starting to sound like a real subsystem. You've got the enhancer prompt with preservation rules and structured output, a "refuse to enhance" path that short-circuits the whole thing, and a separate validation step that diffs the output against the input. That's not a button anymore. That's engineering.
It has to be, in an agentic context. The consumer "enhance" button can afford to be sloppy because the human is the validator. In an agentic pipeline, you have to build the validation into the system. And even with all of that, you still need to know when not to use an enhancer at all.
Let's go through that. When is the enhancer the wrong call?
Four cases. First, when the user's input is already well-structured and specific — the enhancer adds no value and only introduces risk. Second, when the downstream model is already instruction-tuned to handle raw user input — you're adding an unnecessary intermediate step that can only degrade the signal. Third, when the cost of hallucination is high — medical, legal, financial advice — the fabrication risk outweighs any conceivable benefit. And fourth, when the user is an expert who knows exactly what they want — the enhancer's helpfulness becomes interference, as we said.
That third one is worth sitting with. If you're building a system that gives legal advice, and your enhancer hallucinates a jurisdiction-specific requirement — "file within thirty days" when the user's jurisdiction allows sixty — that's not a cosmetic error. That's malpractice-by-proxy.
And the user never sees it. The enhancer added "thirty days," the downstream agent incorporated it into the advice, and the user acted on it. The hallucination is invisible and consequential. That's the nightmare scenario.
So for high-stakes domains, the safest enhancer is no enhancer.
Or an enhancer that is so heavily constrained it's essentially a formatter — it standardizes the structure of the input without touching the content. But even that requires careful testing.
Which brings us to evaluation. Daniel's question about this was pointed — how do you know if your enhancer is helping or quietly degrading things, given there's rarely a ground-truth correct enhanced prompt to compare against?
This is the hard part. You can't just say "does the enhanced prompt look better" because "looks better" is subjective and, as we've established, the enhancer is optimized to produce things that look better. You need indirect measures.
Walk me through the approaches.
The first is round-trip testing. You take an original user input, run it through the enhancer, feed the enhanced prompt to the downstream model, and then use a separate evaluator LLM to extract the user's original intent from the downstream output. Then you compare the extracted intent to the original input. If the extracted intent differs — if a constraint is missing or a new one appeared — the enhancer introduced drift.
So you're measuring whether the user's intent survived the full pipeline.
And intent survival is the metric that actually matters. Not "is the enhanced prompt more detailed," not "does it score higher on some rubric." Did the thing the user wanted actually make it through to the output? If the enhancer dropped "no admin rights" and the script requires admin rights, the round-trip test catches that.
And you can automate this at scale. Run a hundred diverse inputs through the pipeline, run the evaluator on each output, count the drift cases.
Right. The second approach is simpler — A/B testing with real user satisfaction metrics. Route some fraction of traffic through the enhanced path and some through the unenhanced path. Measure task completion rates, user ratings, re-query rates — anything that signals whether the user got what they wanted. If the enhanced path doesn't outperform the unenhanced path, your enhancer is dead weight.
Or worse than dead weight — it's adding latency and compute cost for negative value.
Which is shockingly common. I've seen teams deploy enhancers, measure latency go up by three hundred milliseconds, and never stop to check whether anything actually improved. They just assumed.
The third approach Daniel mentioned was adversarial testing. What does that look like?
You deliberately craft inputs designed to break the enhancer. Specific version numbers — "Python 3.11.4." Obscure file formats — "export to dot XLSX strict XML spreadsheet 2003 format." Contradictory requirements — "make it fast but use only bubble sort." Unusual constraints — "must run on a Raspberry Pi Zero with 512 megabytes of RAM." Then you check whether the enhancer preserved every single one of those details. Most naive enhancers will drop or "improve" at least some of them.
"Bubble sort? The user probably meant an efficient sorting algorithm." And now the contradiction is gone, and the downstream model cheerfully implements quicksort, and the user — who was writing a pedagogical example about why bubble sort is bad — gets something they didn't ask for.
That's exactly the kind of failure adversarial testing catches. And you don't need thousands of test cases — even twenty or thirty adversarial inputs will reveal whether your enhancer has a fidelity problem.
There's one more evaluation approach I want to surface because it's counterintuitive. Before you measure whether your enhancer improves outcomes, measure whether it degrades them. Run a batch of diverse inputs through the pipeline with and without enhancement, and check for regressions in task completion. If the enhancer causes even a two percent regression, its benefits need to be substantial to justify the risk.
The "do no harm" baseline. And most teams skip this step because they're excited about the benefits and don't want to look for the costs. But if you can't clear the "doesn't make things worse" bar, nothing else matters.
It's the Hippocratic oath for prompt engineering.
I was going to say that.
You're the retired pediatrician. I'm allowed to borrow the metaphor.
Fair. But it applies. First, do no harm. If your enhancer is causing regressions, don't deploy it until you understand why. And if you can't fix the regressions, don't deploy it at all.
Let's pull this together into something actionable. If someone's listening and they need to build or evaluate a prompt enhancer for their agentic pipeline tomorrow, what's the checklist?
Four design principles. One: prefer distillation over expansion. Clarify structure, resolve genuine ambiguities, but do not add content the user didn't provide. Two: use structured output with explicit fields for constraints, verbatim sections, and a self-evaluated faithfulness score. The JSON schema is your guardrail. Three: include a "refuse to enhance" clause that returns the input unchanged when it's already specific and unambiguous. Four: implement diff-based validation as a separate step — either a second LLM call or a rule-based check — to catch hallucinated additions before they reach the downstream system.
And for evaluation?
Before you deploy, run a regression test on at least a hundred diverse inputs. Measure task completion with and without enhancement. If the enhancer causes regressions, don't ship it. Then add adversarial testing — twenty or thirty inputs designed to break fidelity. Then set up ongoing monitoring, whether that's round-trip testing on a sample of production traffic or A/B testing with real user metrics. Evaluation isn't a one-time thing — your input distribution will shift, models will get updated, and an enhancer that worked last quarter might be hallucinating this quarter.
The meta-lesson here is that a prompt enhancer is itself a prompt. Every principle of good prompt engineering applies — be specific, constrain the output space, test for failure pattern. The enhancer isn't magic. It's a tool with sharp edges, and treating it as an automatic improvement is how you get cut.
The sharpest edge is the one Daniel flagged at the start — the hallucination laundering problem. In an agentic pipeline, the enhancer's output is ground truth. Every downstream step builds on it. A fabrication at the preprocessing layer doesn't stay contained — it propagates. By the time the user sees the result, the hallucination is buried under layers of agent actions, and tracing it back to the enhancer is difficult.
Which is why the "when in doubt, leave it out" principle matters. If you can't measure a clear benefit from your enhancer, or if the cost of hallucination is too high for your domain, the safest choice is to not use one at all. An agent that occasionally gets confused by messy input is better than an agent that confidently acts on fabricated requirements.
That's the thing — we're so focused on making the system understand the user better that we forget to ask whether the enhancer actually does that. It makes the prompt more detailed, more structured, more like what the model expects. But does it preserve what the user meant? Those are different things.
The enhancer is supposed to help the model understand you better. But if it rewrites what you said, does it still understand you at all?
That's the question. And I think the answer depends entirely on how you build it. A well-constructed enhancer with preservation rules, structured output, refusal logic, and validation can improve outcomes — especially for vague or underspecified inputs. A naive enhancer with an expansion directive is a hallucination machine with a permission slip. The difference is engineering discipline.
The willingness to measure whether it's actually working, which is the part most teams skip.
Most teams skip measurement because measurement is hard and "the prompt looks better" is easy. But "looks better" is not a metric. Task completion is a metric. Intent preservation is a metric. User satisfaction is a metric. If you're not measuring those, you're not evaluating your enhancer — you're just admiring it.
Daniel also asked about where this is heading. As enhancers get more sophisticated — retrieval-augmented generation, few-shot examples, maybe even fine-tuned models specifically for prompt rewriting — do the fidelity problems get better or worse?
It could go either way. More context — like retrieving relevant documentation or past successful prompts — could help the enhancer make more accurate judgments about what the user probably meant. But more context also gives the model more material to hallucinate from. A fine-tuned enhancer might be more faithful on average, but when it does hallucinate, the hallucinations might be more confident and harder to detect. I don't think sophistication automatically solves the fidelity problem. It might just make the failures more sophisticated.
Which circles back to evaluation. The more capable your enhancer, the more you need rigorous testing to catch what it's doing wrong. Sophistication without measurement is just faster, more confident errors.
That's where I'll land. If you're running a prompt enhancer in production, especially in an agentic pipeline, we want to hear about your evaluation methodology. What metrics do you actually use? Have you caught your enhancer hallucinating? What did the failure look like, and how did you find it? Email the show at show at my weird prompts dot com. These war stories are how the practice improves.
The core tension doesn't go away. The enhancer is an intermediary between what you said and what the system hears. Every intermediary is a potential point of distortion. The question isn't whether distortion happens — it's whether you've built a system that catches it before it matters.
Thanks to our producer Hilbert Flumingtop for keeping this show running.
This has been My Weird Prompts. Find every episode at my weird prompts dot com.
We'll be back soon.
