/
← Previous L2: Few-Shot Prompting for Consistency →
Module 4 — Prompt Engineering for Reliable Agent

L1: Explicit Criteria and Instruction Design

L1: Explicit Criteria and Instruction Design

Explicit Criteria and Instruction Design

Up until this point, we have focused heavily on the infrastructure surrounding the model (agents, SDKs, hooks, and MCP servers). In Module 4, we shift focus to the model's core engine: Prompt Engineering.

For an AI Architect, prompt engineering is not "talking to a chatbot." It is a deterministic programming language where English is the syntax. This lesson covers how to write explicit, measurable instructions that prevent the model from guessing your intent.

1. The Illusion of Human Communication

When humans assign tasks to other humans, we rely heavily on implicit context. If you tell a junior developer, "Summarize these error logs," they instinctively know to focus on critical errors, ignore standard info logs, and format it in a readable way.

The Architectural Failure: If you give Claude that exact same prompt, it might return a 5-page chronological summary, a haiku about the errors, or a JSON array. Claude does not share your implicit human context.

  • To achieve production-level reliability, every implicit assumption must be translated into an explicit rule.

2. Defining Explicit Criteria (Measurability)

The foundation of instruction design is ensuring that your criteria for success are mathematically or logically measurable. If a rule involves an adjective, it is likely too vague.

  • Vague (Fails in Production): "Make the email sound professional." (What is professional? Corporate? Friendly but formal?)

  • Explicit (Production-Ready): "Use a formal corporate tone. Do not use exclamation points. Address the user by their last name. Limit the email to exactly 3 paragraphs."

If a human reviewer cannot read the prompt and immediately determine a true/false pass rate for the output, the instructions are not explicit enough for an LLM.

3. Structural Design and XML Tags

LLMs, particularly the Claude family, are heavily trained to recognize structure. Writing a massive block of continuous prose confuses the model's attention mechanism.

Anthropic's Best Practice: XML Tagging

Architects should use standard XML-style tags to segment the prompt into distinct logical blocks. This physically separates the rules from the data, preventing prompt injection and improving Claude's parsing accuracy.

XML

<role>
You are a Tier 2 Database Reliability Engineer.
</role>

<instructions>
1. Read the <error_logs> provided below.
2. Identify the root cause of the database timeout.
3. Output a mitigation plan.
</instructions>

<constraints>
- Do not suggest restarting the primary cluster.
- Only reference tools available in your schema.
</constraints>

<error_logs>
[Dynamic Data Injected Here]
</error_logs>

Architectural Advantage: When you structure prompts this way, Claude inherently understands that it must obey the <instructions> while treating the <error_logs> merely as passive data to be analyzed.

4. The Core Instruction Framework

Every production prompt should follow a standard framework to ensure complete coverage.

  1. Role/Persona: Set the operational baseline. ("You are an expert PostgreSQL DBA.") This tunes the model's probabilistic weights toward a specific domain's vocabulary.

  2. Context/Goal: What is the overarching objective? ("We need to migrate table X to table Y without downtime.")

  3. Step-by-Step Instructions: Force the model into a deterministic path. Numbered lists are highly effective. If step 2 must happen before step 3, number them explicitly.

  4. Constraints (Negative Prompts): Tell the model exactly what not to do. LLMs are eager to please and will over-generate if not constrained. ("Do NOT include introductory greetings. Do NOT explain your reasoning. Just output the final SQL query.")

5. Edge Case Handling (The "If-Then" Fences)

The most common point of failure in instruction design is ignoring edge cases. What happens if the data the model needs is missing?

If your prompt is "Extract the total revenue from the transcript," and the transcript does not mention revenue, Claude will often hallucinate a number to fulfill the instruction.

The Fix: Explicit Escape Hatches

You must design "If-Then" logic into the prompt to give the model a safe way to fail.

  • "Extract the total revenue from the text.IF the text does not contain revenue figures,THEN output exactly the string 'DATA_MISSING' and stop." By giving the model an explicit, sanctioned failure state, you eliminate the pressure to hallucinate and provide your application code with a predictable string (DATA_MISSING) to trigger an escalation or error handling routine.