Prompt Engingeering Daily
All Episodes
Self-Critique Prompts That Keep AI Agents on Track

Self-Critique Prompts That Keep AI Agents on Track

0:00|0:00

Explore why production AI agents spend most of their context on system instructions yet still drift without structured self-critique. The episode breaks down the Dual Role Critic Executor pattern, XML-tagged reflection loops, and the plan-and-execute approach that helps multi-step agents stay accurate.

This show was created with Jellypod, the AI Podcast Studio. Create your own podcast with Jellypod today.


Chapter 1

The Self Correction Loop Prompt Deconstructing Reflection Architecture

Claire Brooks

Have you, uh, have you ever looked at what is actually sitting inside the system prompt of a production AI agent?

Ethan

Oh, man. It is, it's usually an absolute disaster zone. Pages and pages of instructions, right?

Claire Brooks

It really is. Datadog put out an analysis of production AI applications, and get this: 69 percent of all LLM input tokens in production agentic applications are consumed by system prompt instructions. 69 percent!

Ethan

Wait, wait. Almost 70 percent of the context window is just telling the model how to act before it even reads a single user message?

Claire Brooks

Before it reads a word of user input! But, uh, here is the kicker. Despite cramming all those rules into the prompt, if you leave the agent to run without a structured self critique loop, it still suffers from logic drift. It just wanders off off the rails.

Ethan

Because, I mean, telling a model to be careful in plain English is, it's like telling a distracted dog to be good. It works for about two seconds, and then, uh, then something shiny happens.

Claire Brooks

Exactly. So developers are turning to a very specific prompt architecture pattern. It is called the Dual Role Critic Executor system prompt template. And the key to making it work isn't just telling it to review its work, it's strictly isolating its internal trial and error using XML tags.

Ethan

Right, like, like separating the scratchpad from the final answer.

Claire Brooks

Precisely. You enforce four distinct tags in the prompt structure: tag one, working memory scratchpad, or thought scratchpad. Tag two, draft output. Tag three, critic eval. And tag four, final response.

Ethan

So, so the model is forced to literally write out its reasoning in thought scratchpad, drop a rough draft in draft output, then switch hats inside critic eval to roast its own draft, and only then write the final response?

Claire Brooks

Yes! And the layout mechanics here are critical. You don't put the evaluation criteria at the bottom of the prompt as a afterthought. You place the evaluation criteria, like correctness, completeness, edge case checks, directly above the draft generation block.

Ethan

Huh. Why does the placement matter so much?

Claire Brooks

Because of how transformer attention mechanisms work. By placing the critique criteria right before the draft generation block in the sequence, you force the model's self attention weights to hold those constraints active while it generates the draft. Research cited by Redis in 2025 showed that applying this Reflection pattern lifted HumanEval coding benchmark accuracy from 80 percent all the way to 91 percent!

Ethan

That is a massive jump. An eleven percentage point gain just from prompt layout and self critique.

Claire Brooks

It is massive. Did you, uh, haven't you run into this exact issue when you were building code tools?

Ethan

Oh, don't remind me. I, I built this automated pull request reviewer agent last year. I thought I was being clever, you know? I wrote this long system prompt telling it, hey, check for syntax errors, check for security flaws, check for style guide adherence. And I just let it run in a single pass.

Claire Brooks

And what happened?

Ethan

It was, it was awful! It would constantly miss blatant syntax bugs. It would gloss over off by one errors, and then give this glowing review like, LGTM, looks great to me! I was losing my mind trying to figure out why it kept nodding along to broken code.

Claire Brooks

So how did you fix it?

Ethan

I had to completely restructure the system prompt. I added an explicit critic eval gate in XML. I made it write out every line of code it doubted into critic eval, test it against three explicit failure criteria, and if it failed any criteria, it had to explicitly write rejected in the tag and try again. The second I forced that gate, the false approval rate plummeted.

Claire Brooks

It's crazy how much forcing a model to pause and critique itself changes the downstream output. But what happens when the task isn't just reviewing code, but taking ten sequential steps to solve a huge problem?

Chapter 2

The Plan and Execute Blueprint Taming Complex Multi Step Workflows

Ethan

Well, that brings us right to the big wall everyone hits in production, right?

Claire Brooks

Yeah, execution wander. The LangChain 2026 State of AI Agent Engineering Report found that 32 percent of practitioners cite output quality as their single biggest blocker to deploying agents into production.

Ethan

32 percent. One in three teams stuck in development hell because their agents start out strong and then drift into nonsense by step four.

Claire Brooks

And the root cause is almost always trying to make the model reason and call tools in the exact same breath. When a model is doing open ended reasoning on the fly while simultaneously selecting tool parameters, it suffers from cognitive overload. It loses sight of the original goal.

Ethan

It's, it's like asking a chef to cook a five course gourmet dinner for fifty people, but you tell them, hey, don't write down a menu, don't check your pantry inventory beforehand, just start chopping onions and figure out course four while you fry fish for course two.

Claire Brooks

That is such a perfect image! Of course the dinner is going to be a train wreck.

Ethan

Right! You end up with raw chicken and ice cream on the same plate because nobody planned ahead.

Claire Brooks

So the solution in prompt engineering is the Plan and Execute pattern. Specifically, structuring the system prompt using a DAG Planner blueprint. DAG, as in Directed Acyclic Graph.

Ethan

Break down the prompt blocks for that. How do you lay that out?

Claire Brooks

You divide the system prompt into four clear, sequential layout blocks using bracketed headers. Block one is bracket ROLE bracket, defining the scope. Block two is bracket CONSTRAINTS bracket. Block three is bracket STEP DECOMPOSITION bracket. And block four is bracket EXECUTION CONTRACT bracket.

Ethan

Wait, why put CONSTRAINTS in block two before STEP DECOMPOSITION in block three?

Claire Brooks

That positioning is the entire trick! If you put task decomposition first, the model starts spitting out steps based on unconstrained defaults. By positioning parameter constraints like budget limits, output formats, and prohibited actions BEFORE the task decomposition directive, the model is forced to evaluate every proposed step through the lens of those constraints during generation.

Ethan

Ah, so it can't plan a step that violates a constraint because the constraint token history is already sitting right above it in the processing stream.

Claire Brooks

Exactly. It prevents scope creep during middle execution steps. The execution contract block then specifies that the planner agent cannot execute any steps itself. It can ONLY output a structured plan, which is then handed off to a separate, lightweight executor agent that runs each step sequentially.

Ethan

So you split the brain! One model does the heavy lifting of mapping out the path, and another focused model just follows the map line by line.

Claire Brooks

Exactly. And according to that same LangChain report, separating planning from execution directly targets both that 32 percent quality blocker and the 20 percent latency blocker that teams face, because independent steps in the plan can be executed in parallel.

Ethan

That makes total sense. But, uh, what happens when the executor agent actually tries to use a tool, and the tool returns garbage?

Chapter 3

The Defensive Tool User Prompt Preventing Schema Hallucination and Token Waste

Claire Brooks

Oh, tool calling failures! That is where prompts go to die, Ethan.

Ethan

It really is. You know, people think tool calling is just passing a JSON schema to an API, but in practice, APIs break all the time. They return empty JSON payloads, 404 errors, rate limits, unstructured HTML error pages.

Claire Brooks

And if your prompt hasn't trained the agent on how to handle tool failures, what does the agent do?

Ethan

It panics! Or worse, it hallucinates a fake success response and keeps going as if everything is fine, burning hundreds of tokens along the way.

Claire Brooks

Right! Remember that statistic from Datadog we mentioned earlier? 69 percent of input tokens in production agents are system prompts. A huge portion of those tokens are bloated, poorly formatted tool definitions. When you have ten tools defined with vague parameter descriptions, you are wasting money and begging for schema hallucinations.

Claire Brooks

So the pattern here is called the Schema Sandbox and Guardrail prompt template. Instead of putting generic error handling instructions at the very bottom of your master prompt, like, if a tool fails try again, you embed micro error handling directives directly inside the individual tool schema parameter descriptions.

Ethan

Wait, inside the parameter description itself?

Claire Brooks

Yes! Literally writing directives like IF tool returns empty payload THEN return fallback JSON format X into the description string of the schema parameter.

Ethan

Whoa. That's, that's clever because when the model selects that tool, the attention mechanism is reading the field definition at the exact moment it formats the input. It doesn't have to scan back up to a general instructions section five thousand tokens away.

Claire Brooks

Spot on. It isolates the fault domain to that specific micro tool schema. But here is where prompt engineers are currently having a massive debate. Ethan, where do you stand on few shot exemplars for tool prompts?

Ethan

Oh, man. Okay, so look. With frontier models today, GPT 4o, Claude 3.5 Sonnet, Gemini 1.5 Pro, a lot of people argue that zero shot reasoning is so good that adding few shot exemplars, you know, example inputs and outputs in the prompt, is just a waste of tokens.

Claire Brooks

Right, why pay for two thousand tokens of example tool calls when the model understands JSON schemas natively?

Ethan

Exactly! That is the argument. But I, I strongly disagree for production systems. Zero shot works great in happy path testing. But when you hit edge cases, like nested optional parameters or weird API responses, zero shot fails predictably. You NEED edge case exemplars in the prompt if you want production stability.

Claire Brooks

I, uh, I hear you, but isn't there a cost trade off? If 69 percent of your tokens are already system instructions, adding five multi turn exemplars for every tool doubles your token overhead. In high throughput applications, that will wreck your API bill!

Ethan

Sure, it costs more tokens per call, but what costs more? Paying twenty percent more for input tokens, or having an agent enter a retry loop five times because it generated an invalid JSON schema?

Claire Brooks

Fair point. Retries burn both tokens and latency.

Ethan

Exactly. A failed tool execution loop burns thousands of output tokens, which are way more expensive than prompt input tokens anyway. Exemplars pay for themselves by preventing retries.

Claire Brooks

Okay, I can see that logic. But what happens when an agent conversation runs for twenty or thirty turns? Even with defensive tool prompts, eventually your context window gets bloated with past conversation history.

Chapter 4

The Context Pruning Memory Prompt Dynamic Backroom Summarization

Ethan

Ah, the dread central layer attention decay. Otherwise known as needle in a haystack syndrome.

Claire Brooks

It is a huge issue. Modern models technically have massive context windows, one million, two million tokens. But research continuously shows that as the context grows, models suffer from attention decay in the middle layers. They remember the system prompt at the start, they remember the latest message at the end, and everything in the middle becomes a blurry haze.

Ethan

After 15 to 20 conversation turns, if you just keep appending raw chat history, the agent starts forgetting core instructions or repeating actions it already took ten turns ago.

Claire Brooks

I actually ran into this exact problem last month during a research project! I was building a custom search agent to synthesize legal documents across long conversational threads. Around turn 18, the agent completely forgot the core search filters I set in turn two. It started pulling records from the wrong jurisdictions because the raw chat history drowned out the original parameters.

Ethan

It just washed away in the flood of tokens.

Claire Brooks

Literally flooded out. So how do we fix this with prompt engineering? We use the Rolling Memory Index system prompt template.

Ethan

How is that structured?

Claire Brooks

You configure four persistent state blocks in the system prompt: tag working memory, tag episodic log, tag active goals, and tag pruning rules.

Ethan

Okay, walk me through how those operate during a turn.

Claire Brooks

Here is the magic trick. Before the agent is allowed to write its main response to the user, the prompt mechanics require the model to execute a three line update inside working memory. It MUST evaluate the latest turn, extract key entities or state changes, update active goals, and prune expired context from episodic log.

Ethan

Wait, so context management isn't done by a background Python script or an external database call? It's done inline by the prompt layout itself?

Claire Brooks

Yes! It transforms context management into an inline state machine inside the model's own generation loop. By forcing that working memory update first, you can compress 50 history turns, which might be 20,000 raw tokens, down into a clean 150 active tokens in working memory.

Ethan

That is brilliant. You keep the context window perpetually fresh, eliminate central layer attention decay, and keep your token costs flat regardless of how long the conversation goes.

Claire Brooks

Exactly. But as we make agents smarter, more autonomous, and better at managing their own memory, we hit the ultimate question: how much authority do we actually give them?

Chapter 5

The Human in the Loop Safeguard Prompt Escalation and Governance

Ethan

And that is where enterprise leaders are sweating right now. The automation dream versus the nightmare of an agent running wild.

Claire Brooks

UiPath released an Enterprise Automation Report that found 93 percent of IT leaders plan to deploy autonomous AI agents within the next two years. 93 percent! But unmonitored agentic actions remain the single top organizational risk factor holding deployments back.

Ethan

Because if an agent sends an unauthorized email, executes an incorrect financial transaction, or deletes a database record, you can't just blame the LLM. That's on you.

Claire Brooks

Right. Human in the Loop isn't a hack or a sign that your agent failed. It is a fundamental architecture choice. To enforce it at the prompt level, developers use the Autonomy Spectrum and Escalation Trigger prompt template.

Ethan

What are the core sections in that template?

Claire Brooks

It relies on three strict governance sections using bracket headers: bracket PERMITTED ACTIONS bracket, bracket HIGH RISK TRIGGERS bracket, and bracket HUMAN CHECKPOINT SCHEMA bracket.

Ethan

How do you define when the agent needs to stop and ask for human approval?

Claire Brooks

You embed numerical confidence thresholds and action severity tiers inside the instructions. For example, low risk actions like querying a public API are auto approved. High risk actions like modifying a database or issuing a refund over 100 dollars trigger a hard policy break.

Ethan

And what does the agent output when a policy break is triggered?

Claire Brooks

Instead of calling the tool or giving a final answer, the prompt mechanics force the model to output a paused XML block: tag status PENDING APPROVAL tag status. Inside that block, it provides a structured human summary, the proposed tool call payload, and a risk score justification.

Ethan

So the agent literally freezes its own execution state, hands the JSON payload to a human dashboard, and waits until a human signs off before the execution resumes.

Claire Brooks

Exactly. It turns risky autonomous workflows into safe, supervised workflows without breaking the underlying software architecture.

Ethan

Man, looking at all five of these patterns, Dual Role Reflection, DAG Planners, Defensive Tool Schemas, Rolling Memory Indices, and Escalation Safeguards... it really shows how much prompt engineering has evolved from, you know, just writing clever text into actual system architecture.

Claire Brooks

It really has. But here is the question I keep asking myself, Ethan. Do you think we are going to be hand crafting these complex multi block XML system prompts five years from now? Or are automated meta prompt engines going to render human prompt layout completely obsolete?

Ethan

Hmm. I, I think the syntactic details, like exactly where to put XML tags or how to write JSON schemas, yeah, compilers and meta prompt tools will automate a lot of that. But the underlying architectural principles? Knowing when to force a reflection loop, when to split planning from execution, where to place human checkpoints? That architectural intuition isn't going anywhere.

Claire Brooks

That feels right to me. The syntax changes, but understanding failure modes is what keeps systems alive.

Ethan

Well, that is our deep dive into agentic prompt engineering for today! Go audit your system prompts, check your token consumption, and put some guardrails on those agents.

Claire Brooks

Alright, good chatting, Ethan. Talk soon!