Prompt Engineering Discipline — CCA-F Domain Three Through the Lens of Production Agent Workflows
The system prompt is a contract. Write it as one.
§ IFrame
A system prompt is a contract. The model accepts it as the frame within which every user turn is interpreted. Write it loosely and the frame bends. Write it precisely and the model works the corner cases you forgot.
CCA-F's Domain Three — Prompt Engineering, weighted at 20% — tests whether a practitioner can construct prompts that produce reliable outputs across production agent workflows. The domain is not about clever tricks. It is about the engineering discipline that makes a model's behavior predictable at scale.
This lesson works through the five core techniques the domain covers, applies each to the production agent context the arc has built across prior lessons, and closes with five practice questions.
§ IIDomain Foundation: Probabilistic Nature and What That Demands
Huyen's AI Engineering (Ch. 2, pp. 130–131) frames the key insight. A model's output is probabilistic. The same input does not guarantee the same output across calls. Temperature, sampling strategy, and the model's training distribution all introduce variance. The engineer's task is not to eliminate variance — it cannot be eliminated — but to reduce it to an acceptable band.
In production, "acceptable" means the agent's routing decisions, output shapes, and tool-call choices fall within the harness's parse and validation logic on every call. Prompt engineering is the primary instrument for that reduction. A well-structured system prompt constrains the output distribution toward the intended region. A poorly structured one leaves the model sampling freely across the full distribution, which means the harness encounters the tails.
Five techniques reduce variance along five different axes.
§ IIIThe Five Techniques
The system prompt is not a description of what the agent does. It is an instruction set for how the agent reasons.
Description form: "You are a trading assistant that helps with market analysis."
Instruction-set form: classify queries as MARKET_PULSE / POSITION_QUERY / STRATEGY_INQUIRY / OUT_OF_SCOPE; for each class, specify the exact action; specify what you never do.
The instruction-set form gives the model a decision tree. The description form gives the model a role and leaves the decision tree implicit. Implicit trees produce inconsistent behavior. Explicit trees produce predictable routing.
Few-shot prompting provides 2–4 input-output pairs before the live query. Each exemplar is a vote for a particular output region. The discipline: exemplars must cover edge cases, not just central cases. The model needs to see the negative case — an ambiguous input classified as OUT_OF_SCOPE — to route it correctly.
The anti-discipline: exemplars so similar to the live input that the model memorizes rather than generalizes. Vary the surface wording; hold the structural classification. Three exemplars identical in phrasing except for the ticker name is one exemplar, not three.
Instruct the model to produce its reasoning before its answer. The instruction is direct: "Before responding, state your classification reasoning in <reasoning> tags." The effect: the reasoning is visible in the output and the harness can check it. An answer of MARKET_PULSE with reasoning that says "the user is asking for a trade recommendation" is a signal worth catching. The harness logs the inconsistency and escalates.
For tool-call decisions: "Before calling any tool, state what you will call and why." This makes agent intent observable before execution — the basis for pre-tool approval gates.
"Respond in JSON" is an aspiration, not a specification. The specification is the schema — exact field names, types, permitted enum values, and the instruction "No prose before or after the JSON block."
Production discipline: the harness validates the output against the schema before routing. If parsing fails, retry with an error-correction prompt. One retry is standard. Two retries signal the system prompt is under-specified; refactor rather than adding a third retry.
Temperature controls output distribution width. For classification and structured-output tasks: 0.0–0.3. For generation tasks where diversity is wanted: 0.7–1.0. Set temperature explicitly for every production prompt — API defaults vary by model version; explicit settings are version-stable.
§ IVProduction Application: The WITHDRAWAL Exit-Gate Agent
The WITHDRAWAL protocol's four-leg exit gate is a classification problem. An agent monitors ETF flow data and classifies each day's print into one of four gate states: pre-gate, leg-1-candidate, tracking, or exit-signal.
All five techniques applied simultaneously:
System prompt: instruction-set form naming all four gate states with explicit numeric conditions (leg-1-candidate = IBIT + FBTC both positive ≥ $50M on the same print day). Few-shot: one clean case, one ambiguous case, one out-of-scope query. Chain-of-thought: "Before classifying, state which funds reported flows and their directions." Output format: {"gate_state": "...", "funds_positive": [...], "funds_negative": [...], "reasoning": "..."}. Temperature: 0.0 — classification, not generation. No variance is acceptable here.
This agent, built under the five-technique discipline, routes consistently across calls. The harness validates the output schema, logs the reasoning for audit, and routes the gate state to the position-sizing module.
§ VConnection to Today's Ops and Dev Lessons
The Ops lesson today defined the API contract between frontend and backend. Prompt engineering defines an analogous contract between the agent harness and the model. The system prompt is the schema the model must honor. The output format specification is the envelope the harness expects. The temperature setting is the sampling parameter that governs variance — structurally parallel to max-age governing cache freshness.
Both disciplines require an explicit document, a machine-checkable output shape, and a retry policy for when the contract is violated. Write them the same way.
§ VIPractice Questions
An agent classified user inputs with 95% accuracy in testing. In production, accuracy dropped to 78%. Logs show that production inputs have longer, more complex phrasing than test inputs. Which technique most directly addresses this?
You use chain-of-thought prompting. The model's reasoning says "I should call search_tool" but its actual tool call is get_transactions. Which production discipline does this support?
A classification system prompt specifies five output classes. In production, the model occasionally returns a sixth class not in the specification. What is the immediate fix and the systemic fix?
You need the same base model for two tasks: strict JSON classification and brainstorming new trading strategy ideas. How should temperature be configured?
A CCA-F exam question asks: "What is the primary purpose of specifying an output format schema in the system prompt?" Which answer is correct?
§ VIIClosing
The system prompt is a contract. Write it as one: explicit decision trees, exemplars that cover the failure modes, output schema the harness validates on every call, temperature set explicitly for the task type.
The model works the corners you specify. The corners you leave to discretion are the ones that produce incidents.
Examine the system prompt on the last agent you built. Is it a description or an instruction set? Does it carry exemplars? Does it specify the output schema? Does it set temperature? If any of those questions returns "no," you have variance you did not choose.
Paired lessons → Ops 01-Earth-DevOps/2026-06-28-the-api-contract-... · Dev Polyglot-Dev/Web/2026-06-28-driving-threejs-...
Filed 2026-06-28 Sunday Fajr · Cert Anthropic Day · CCA-F Domain Three (Prompt Engineering, 20%)
Backward-Synergy-Reach → Claude Code as Operator's Harness (D2 06-21) · Context Management (D5 06-14)
HTML shipped in-cycle per HARD DISCIPLINE · aether-accent meta-card · tome: Huyen AI Engineering Ch2 pp130-131