Here's what Daniel wrote to us. Quote — "Writing system prompts is an underrated but incredibly versatile craft in AI prompt engineering. I've always thought we don't spend nearly enough time talking about how to combine positive and negative instructions effectively." He's built a prompt processor that takes his dictated podcast prompts, cleans them up, catches transcription errors. And he hit a failure mode. The enhancement node kept inventing follow-up questions — ten or fifteen of them — pulling the discussion in directions he never intended. The fix was one line: "Do not add additional questions to the prompt." That single negative instruction solved what a dozen positive ones couldn't.
That's a beautiful little case study.
It gets better. He's asking two structural questions. One — does the order of instructions actually matter? He's got a long system prompt with sections on tone, content, formatting, and he's torn between topic-based ordering, where each section pairs a positive with its negative right after, versus grouped ordering, where all positives come first and negatives are collected near the end. Two — should this even be one prompt? Or should he split the work across multiple agents, one for enhancement and one for constraint enforcement? And he's already observed that review agents introduce their own failure pattern — they break formatting, leak reasoning, add explanatory text instead of returning clean output.
He's identified the exact trade-off. More agents means more points of failure.
So where do we even start with this. That single negative instruction — one line — fixed a problem that a dozen positive instructions couldn't. What's actually going on under the hood?
The mechanism is genuinely interesting. An LLM is a next-token predictor — at every step it's sampling from a probability distribution over possible continuations. A positive instruction like "improve clarity" or "preserve tone" steers the model toward certain outputs. It says, here's the direction I want you to go. But a negative instruction does something different — it suppresses entire classes of outputs. It carves out a region of the probability space and says, don't go here. Ever.
So the positive instructions were all pushing toward expansion — "improve," "enhance," "separate questions from context" — and the model was dutifully following that vector. Enhancement, statistically, looks like generating more stuff.
The enhancement node's positive instructions created a strong prior toward elaboration. "Improve clarity" — well, one way to improve clarity is to anticipate what the reader might want to know and ask those questions explicitly. "Separate questions from surrounding context" — that instruction alone practically begs the model to go hunting for implicit questions in the text and surface them as explicit ones. Without a constraint, the model defaulted to generating more questions because that's what the word "enhancement" statistically implies in its training distribution.
So the negative instruction isn't just a guardrail — it's doing fundamentally different work than the positives. The positives define the objective function, and the negative prunes the solution space.
Right. And this is why you can't just rephrase a negative as a positive and expect the same result. "Do not add questions" is not equivalent to "preserve the original question count." The latter is fuzzy — it requires the model to count, to track state, to interpret what counts as a question versus a clarification. The negative is blunt and precise. It says: the output distribution should have zero probability mass on question-generation tokens. That's computationally simpler for the model to enforce.
Which is why Daniel's one line beat a dozen positive instructions. The positives were all steering, and steering is inherently approximate. The negative was a hard constraint.
And constraints are what LLMs are surprisingly good at following — when they're stated clearly. The failure pattern people run into with negative instructions isn't that the model ignores them. It's that the model interprets them too literally or in unexpected ways. "Do not be inappropriate" — the model doesn't know what inappropriate means in this context, so it guesses. "Do not add questions" — that's concrete. There's almost no ambiguity.
So the specificity is doing a lot of the work. "Do not add additional questions" names a specific output behavior. "Be concise" doesn't.
"Be concise" is a vibe. It's a suggestion with no edge.
Alright, so that's the mechanism. Now the ordering question. Daniel's got two structures in mind. Option A — topic-based. Within each section, positive then negative. "Here's what to do with tone, here's what not to do with tone. Here's what to do with formatting, here's what not to do." Option B — grouped. All positives first, all negatives collected near the end. Which one wins?
I'm going to give you an honest answer that might sound like a dodge. There's no definitive benchmark that proves one ordering is universally better. I've looked.
I appreciate the honesty. So what do we actually know?
We know something about attention. OpenAI's prompt engineering guide explicitly recommends placing instructions at the beginning or end of prompts because models pay more attention to those positions. It's the primacy and recency effect — the same thing psychologists have observed in human memory for decades. Early items and late items get weighted more heavily than items in the middle.
So if you bury your most important constraint in paragraph four of a seven-paragraph prompt, the model is statistically less likely to weight it properly.
That's the theory. And it has practical implications for Daniel's two structures. In the topic-based approach — positive then negative within each section — the negatives are scattered throughout the prompt. Some land in high-attention positions, some in low-attention troughs. In the grouped approach — all negatives at the end — every negative instruction sits in a high-attention recency position.
So the grouped structure essentially weaponizes the recency effect. You establish the desired behavior up front, then you hit the model with a concentrated block of "do nots" right before it generates output.
That's the argument. And I think it's a strong one. The grouped structure also has a cognitive benefit — cognitive for the prompt designer, I mean. When negatives are collected in one place, you can review them as a checklist. You can ask, are these consistent with each other? Do any of them contradict the positives earlier? It's easier to maintain.
The topic-based structure has its own argument though. Pairing a positive with its negative immediately creates context. "Improve clarity by simplifying sentence structure. Do not alter the original meaning." The proximity makes the relationship explicit. The model doesn't have to hold the positive in memory across six paragraphs of unrelated instructions before it encounters the corresponding constraint.
That's the trade-off. Proximity versus position. And honestly, I think the model's context window is long enough now that the proximity argument is weaker than it used to be. Modern models can track relationships across tens of thousands of tokens. The recency effect is more robust — it's a fundamental property of the attention mechanism, not a limitation of memory.
So if I'm hearing you right, the grouped structure has a principled advantage — the recency effect — while the topic-based structure has a practical advantage — easier to read and maintain. And the principled advantage probably matters more for model behavior.
I'd lean grouped for exactly that reason. But I'd also say — test it. Daniel's got a prompt processor. He can run the same batch of dictated prompts through both structures and compare the outputs. That's the only way to know what works for his specific use case. Everything we're saying is probabilistic.
Fair. So ordering matters because of attention, the grouped structure exploits recency, but the honest move is to benchmark both. Now let's go bigger. Should this even be one prompt?
This is where the architectural question gets interesting. Daniel's asking whether to go monolithic — one carefully structured system prompt — or multi-agent, with a separate agent whose only job is enforcing negative constraints. Anthropic published a piece on this called Building Effective Agents, and their recommendation is... it depends, but they lean toward simplicity.
The classic consultant's answer. "It depends."
I know, I know. But they're specific about the trade-offs. A monolithic prompt has a single point of control. You tune it, you test it, you ship it. No inter-agent communication overhead. No serialization costs. Every token you spend is on the actual task.
And the downside?
As the prompt gets longer and the constraints get more complex, a single model can lose coherence. It starts to forget or de-prioritize instructions. The attention budget is finite — every additional instruction competes for a share of it. At some point, adding more constraints to a monolithic prompt actually reduces compliance with existing ones.
So the multi-agent approach solves that by giving each agent a narrower job. One agent enhances, another agent strips out unwanted additions.
Separation of concerns. It's the same reason we don't write monolithic software — we break things into functions, modules, services. Each component does one thing and does it well. The enhancement agent never has to think about constraint enforcement. The review agent never has to think about improving clarity. Each has a focused system prompt, and the focused prompt is easier to tune.
But Daniel's already observed the failure pattern. The review agent breaks formatting. It adds explanatory text. It leaks reasoning.
This is a known pattern. Review and editing agents are particularly prone to what I'd call "editorializing" — they want to explain their edits, justify their decisions, show their work. It's almost like the model has learned from human editors who leave comments and track changes. The behavior is deeply ingrained in the training data.
So you solve one problem — unwanted questions — and create another — formatting breakage and reasoning leakage.
And you're paying for both. Every additional agent consumes tokens. The enhancement agent processes the prompt, the review agent processes the enhanced prompt, and if the review agent breaks something, you might need a third agent to clean up the review agent's mess. The costs compound.
What's the actual cost difference? Ballpark.
Depends on the models and the prompt length, but a review pass typically doubles the token spend. If your enhancement prompt is a thousand tokens of input and produces five hundred tokens of output, the review agent needs to process all of that — fifteen hundred tokens in, maybe three hundred out. You've roughly doubled the cost per prompt processed. For a podcast prompt processor that runs a few times a week, that's negligible. For something running at scale, it adds up fast.
So when does multi-agent actually beat a single system prompt?
One — when you have independent constraints that are hard to express in a single prompt. Safety policy enforcement is the canonical example. You want a separate agent checking outputs against a policy that's updated independently, maintained by a different team, with different testing procedures. The separation isn't an optimization — it's an architectural necessity.
And two?
When the main prompt is so long that a single model demonstrably loses coherence. If you've got a system prompt that's five thousand tokens and you're seeing compliance drop on instructions in the middle, splitting the work across agents can restore reliability. But that's a fix for a specific failure pattern, not a default architecture.
For Daniel's case — a prompt enhancement node with maybe a few hundred words of instructions — you'd lean monolithic.
The enhancement node's job is well-defined, the constraints are simple, and the failure pattern he observed with multi-agent — formatting breakage, reasoning leakage — is harder to solve than the original problem. Keep it in one prompt. Structure it well.
And if he absolutely needs a review agent?
Give it an explicit output contract. "Return only the edited text. No commentary. No reasoning. No explanatory notes. The output must be a valid prompt, ready for use, with no additional text before or after." And then test specifically for formatting breakage. Run a hundred prompts through it and check how many come back with extra line breaks, markdown artifacts, or trailing commentary. If the failure rate is above, say, two percent, the review agent is creating more work than it saves.
That output contract is doing the same thing Daniel's original negative instruction did — naming a specific prohibition rather than a vague aspiration. "Return only the edited text" is the review-agent equivalent of "do not add additional questions."
The pattern generalizes. Vague positives are suggestions. Specific negatives are constraints. And constraints are what make prompts reliable.
Alright, let's pull this together. If you were rebuilding Daniel's prompt enhancement node from scratch, what's the playbook?
Four rules. One — use the grouped structure. All positive instructions first, organized by topic — tone, content, formatting. Then a dedicated negative-instructions section near the end. That exploits the recency effect and gives you a maintainable checklist.
Two?
Make every negative instruction as specific as the one that worked. "Do not add additional questions" — not "be concise," not "stay focused." Name the exact behavior you want to suppress. If you can't name it specifically, you don't understand the failure pattern well enough to constrain it.
Three?
Before you add a review agent, ask whether the constraint can be expressed in the main system prompt. If it can, keep it monolithic. Reserve multi-agent for independent policy enforcement or for prompts so long that coherence demonstrably breaks. Default to one prompt.
And four?
If you do use a review agent, give it an output contract that's as specific as your negative instructions. "Return only the edited text." Test it against formatting breakage specifically — don't just eyeball the outputs, run a structured evaluation. And if the review agent's failure rate is higher than the original problem's, kill it.
The through-line in all of this is that Daniel's original fix — the single negative instruction — is the model for how to think about prompt design. It's empirical, it's specific, and it worked because it suppressed an output class rather than vaguely steering away from it.
And he discovered it by observing a failure pattern and iterating. That's the real best practice. Not the grouped structure, not the monolithic architecture — the willingness to test, observe, and refine. The best system prompt is the one you've actually tested against your actual use case.
Which brings up a question I've been turning over. As agentic AI becomes more common, are we going to see standardized patterns for prompt architecture the way we have design patterns in software engineering? The factory pattern, the observer pattern — will there be a "negative-constraint section" pattern, a "review-agent output contract" pattern?
I think we're already seeing the beginnings of it. The OpenAI guide's Identity-Instructions-Examples-Context structure is essentially a design pattern. The grouped-positive-then-negative structure is a design pattern. Anthropic's guidance on when to go multi-agent versus monolithic is a design pattern. They're just not formalized yet.
And the cost calculus is going to shift. Models are getting cheaper. The token cost of a review agent that doubles your spend today might be negligible in two years. But the failure pattern — reasoning leakage, formatting breakage — those are inherent to the architecture, not the price point.
That's the part people miss when they talk about AI getting cheaper. Cost goes down, but failure pattern don't automatically go away. A review agent that leaks reasoning into the output is just as broken at a tenth of a cent per request as it is at ten cents. The economics change — the engineering doesn't.
The skill of writing good system prompts is durable. Even if multi-agent workflows become the default, someone still has to write the prompts for each agent. And the principles — specificity, attention-aware ordering, output contracts — apply at every level of the stack.
The craft scales. That's what I find exciting about this. The thing Daniel figured out with one negative instruction — that insight applies whether you're writing a single prompt or orchestrating ten agents. Name the behavior you want to suppress. Put constraints where the model will actually attend to them. Test against your real data. The fundamentals don't change.
We should probably give Daniel something to walk away with beyond principles. A concrete restructuring of his enhancement node.
Alright. Here's what I'd do. Section one — identity and context. "You are a prompt enhancement node. Your job is to clean up dictated prompts by correcting transcription errors, separating questions from surrounding context, preserving the speaker's tone, and improving clarity. You do not expand, elaborate, or add content." Section two — positive instructions, organized by topic. Tone, content, formatting. Each with specific do's. Section three — negative instructions, all together. "Do not add additional questions. Do not invent topics not present in the original. Do not rephrase questions in ways that change their meaning. Do not add commentary or analysis." Section four — output format. "Return only the enhanced prompt. No preamble. No explanation. The output must be a valid prompt ready for use."
That negative section is doing heavy lifting. Four specific prohibitions, each naming a concrete output behavior.
Notice the output format section is itself a negative constraint. "Return only the enhanced prompt" is the same pattern as "do not add questions." It's constraints all the way down.
The cutting-room floor detail I keep coming back to is that OpenAI's guide explicitly frames system prompts around "what should the model do, and what should the model never do." That's not an afterthought — it's presented as a core structural principle. The negative is not a footnote. It's half the job.
Most people skip it entirely. They write a list of positive instructions and wonder why the model drifts. The "never do" section isn't optional — it's the part that defines the boundaries of acceptable output.
The open question I'm left with — and I think this is where the field is heading — is whether we'll eventually have tools that automatically detect missing negative constraints. You write a system prompt, the tool runs it against a test set, identifies failure pattern, and suggests specific negative instructions to suppress them. "I notice your prompt enhancement node is generating follow-up questions in thirty percent of cases. Consider adding 'Do not add additional questions' to your negative constraints section."
That's essentially automated prompt optimization. There are already research systems that do something like this — they generate candidate prompts, evaluate them against a metric, and iterate. But they're mostly optimizing for positive behavior. The negative-constraint discovery problem is harder because you need to define what failure looks like, and failure is often domain-specific.
Daniel discovered his failure pattern by reading the outputs and noticing the unwanted questions. A tool that flags "your output contains elements not present in the input" would have caught that automatically.
That's a solvable problem. Input-output diffing, essentially. If the output contains semantic content not traceable to the input, flag it. I'd be surprised if we don't see that built into prompt engineering tools within the next year or two.
The through-line here is that the best prompt is the one you've tested — and Daniel's single negative instruction is the perfect example of empirical iteration beating theoretical best practices. He didn't need a design pattern. He needed to observe a failure and name it precisely.
That's the thing to take away. The principles we've discussed — grouped structure, specific negatives, monolithic by default, output contracts for agents — they're useful heuristics. But the real skill is paying attention to what your system actually does and responding to what you observe.
Thanks to our producer Hilbert Flumingtop for making this show happen.
This has been My Weird Prompts. Find every episode at my weird prompts dot com, or email the show at show at my weird prompts dot com.
We'll be back soon. Go write some negative instructions.
