A couple of years ago, getting good work out of a language model felt like knowing a secret handshake. You learned the magic phrases, you added “think step by step”, you role-played the model into an expert, and the output got better. People called it prompt engineering, and for a while it looked like the whole game.
That era is quietly ending, and it is being replaced by something more interesting. The models got good enough at reading plain intent that clever wording on its own stopped being the differentiator. What separates a toy from a system now is not the cleverness of a single instruction. It is whether the thing works reliably the hundredth time, the thousandth time, when an API times out, when the model returns slightly the wrong shape, when one step quietly corrupts the next.
The field has split in two. On one side sits casual prompting, which almost anyone can do well now because the models meet you halfway. On the other side sits the real engineering discipline, where prompts are treated less like clever sentences and more like programmable parts of a system that has to be tested, validated, and trusted in production.
This article is a field guide to that second half. It walks through prompting as a layered discipline, starting from what a language model actually is, moving through the core techniques that shape a single response, and ending with the workflow patterns that turn one fragile prompt into a dependable multi-step system. Read top to bottom, it moves from understanding what a model can do, to controlling how it behaves, to building something reliable on top of it.
Before any technique makes sense, two foundations need to be clear, namely what a language model is and what it means to prompt one.
A large language model is a deep learning model trained on enormous quantities of text, which lets it understand and generate human language across a wide range of tasks such as summarising, translating, answering questions, and writing code. It learns the statistical patterns and relationships between words and concepts at scale, and that is what lets it produce text that is coherent and on-topic.
The important and slightly humbling detail is what it is doing under the hood. Given the partial sentence “The capital of Australia is”, the model completes it with “Canberra”, not because it looked the fact up in a database, but because that continuation is the most statistically likely one based on the patterns it saw during training. It is predicting the next most probable piece of text. Hold onto that idea, because almost every reliability technique later in this article exists precisely because a very capable next-token predictor is still, at heart, a next-token predictor.
Prompting is the practice of crafting the input, the instructions or queries we call prompts, that guide the model toward the response we want. Good prompting comes down to a few habits. Be clear and specific about the task. Provide relevant context. Specify the output format you want. Sometimes, show an example of what good looks like. None of this changes the model itself. It changes what the model has to work with.
The difference is not subtle. Ask “tell me about cars” and you get something vague and unfocused. Ask “write a 100-word summary explaining the difference between battery-electric and hydrogen fuel-cell vehicles, for a high school audience” and you get something genuinely useful. The second prompt is specific, it names the audience as context, and it fixes the length. Same model, completely different value.
In practice there are two common ways a model is deployed, and the difference shapes everything that follows.
A general model, the kind behind a consumer chat product, is first trained in an unsupervised way to predict the next word in a sequence, then retrained on semi-supervised data so it learns to respond helpfully and follow instructions rather than just continuing text. In the first stage it sees billions of sentences like “Once upon a ___” and learns that “time” is a likely completion. In the second stage, when someone asks “how do I bake bread?”, it produces a structured recipe rather than rambling on with statistically likely words. That second stage is what turns a text completer into something that behaves like an assistant.
An API-based model, the kind you build software on top of, is supplied with two distinct kinds of instruction. The system prompt is the overarching directive that sets the model’s persona, behaviour, and constraints for the entire interaction. The user prompt is what the person wants on each individual turn. The system prompt persists across the whole session. The user prompt changes from message to message.
A small example makes the split concrete. A system prompt of “you are a friendly Python tutor who explains concepts using simple analogies and short code examples” sets a persona that holds for the whole conversation. The user prompt “explain what a list comprehension is” is just this turn’s request. This system-versus-user distinction is the foundation that every technique below builds on.
With the foundations in place, the next layer is the set of techniques that control a single model call. These are the building blocks. The workflow patterns later assemble them into systems.
The system prompt is the natural home for telling the model how to behave, and the most common way to do that is to give it a role.
Role-based prompting assigns the model a specific identity or persona to inhabit, which produces outputs that are specialised and consistent with that role. Telling the model to act as a particular expert or character shapes its tone, vocabulary, and reasoning style, and the effect is striking.
Ask “explain blockchain” with no role and you get a generic, jargon-heavy description. Tell the model “act as a children’s book author, explain blockchain to an eight-year-old using a story about trading marbles in a schoolyard” and you get an engaging, analogy-driven explanation a child could follow. Tell it instead “act as a financial regulator presenting to a parliamentary committee” and you get a formal, risk-focused briefing fit for policymakers. Same topic, three different worlds, decided entirely by the role.
Role-based prompting shapes who the model is. The next technique shapes how it reasons.
Chain of Thought encourages the model to generate a sequence of intermediate reasoning steps before giving its final answer. Instead of asking only for the answer, you guide it to work through the problem step by step. This matters most for tasks that need logical reasoning, calculation, or multi-stage analysis, because making the reasoning explicit reduces the chance of a skipped step.
Consider this. A delivery van leaves the depot with 24 parcels, drops 7 at the first stop and 9 at the second, then picks up 4 more. How many remain? Asked cold, a model might just blurt “11” or “12”. Prompted with “let’s think step by step”, it reasons properly. Start with 24. After the first stop, 24 minus 7 leaves 17. After the second, 17 minus 9 leaves 8. After picking up 4, 8 plus 4 gives 12. Final answer, 12. The explicit chain makes the answer both more reliable and far easier to check, which matters enormously once a human is no longer reading every output by hand.
Chain of Thought is powerful for anything the model can solve from what it already knows. It cannot tell you today’s weather, the current share price, or what sits in your private database. ReAct closes that gap by letting the model act on the outside world, turning a pure reasoner into something much closer to an agent.
ReAct stands for Reason plus Act. It combines Chain of Thought reasoning with the ability to call tools, which lets the model handle tasks that need several rounds of interaction with external information. The heart of it is a loop with three phases.
In the Thought phase, the model reasons about the situation and plans its next specific step toward the goal. In the Action phase, it specifies a tool to use, a web search, a calculator, an API, with the right parameters, and an orchestrator program actually runs that tool. In the Observation phase, the model receives the result of that action, the search hits, the calculator output, the confirmation an email was sent, and that new information feeds back into the next Thought.
Walk through “what is the weather in Melbourne today, and should I bring an umbrella?”. The model thinks, I need current weather for Melbourne, which I do not know. It acts by calling get_weather(location="Melbourne, AU"). It observes the result, {"temperature": 18, "rain_probability": 80, "conditions": "afternoon showers expected"}. It thinks again, an 80 percent chance of rain means an umbrella is sensible, and I now have enough to answer. It replies, 18 degrees with an 80 percent chance of afternoon showers, yes bring an umbrella. The loop runs until the model decides it knows enough to respond. Hold onto ReAct, because it reappears later as the place where reliability matters most.
Every technique so far depends on the quality of the prompt driving it. Prompt instruction refinement is the meta-skill of evaluating and adjusting a prompt to get more precise output, and it improves every technique above without introducing any new mechanism. This is the part of the discipline that is genuinely an engineering skill rather than a trick, and it works by tuning five distinct components.
Role changes the persona and perspective. “Helpful assistant” and “sceptical historian” produce very different work. Task changes the core action and its constraints. “Summarise this” is not “translate this” is not “write a poem under 50 words”. Output format dictates the structure, bullet points or paragraphs, JSON or plain text. Examples refine the style and quality by demonstrating the pattern you want. Context sets the background and scope the model works within.
Watch a vague prompt become a useful one by adjusting each component in turn. The original is just “summarise this article”. The refined version sets the role to “you are a science journalist writing for a general audience”, the task to “summarise the article in three bullet points”, the format to “each bullet under 20 words”, adds an example such as “researchers found electric buses cut urban emissions by 60 percent compared to diesel”, and fixes the context to “focus on practical implications rather than technical detail”. The refined prompt produces a focused, audience-aware, format-compliant summary. The original produces a coin toss. Notice too that these five components are exactly the levers you would expose if you were turning a prompt into a reusable, parameterised piece of software, which is precisely where the field is heading.
Here is where prompting stops being about single responses and becomes about systems. A perfectly refined single prompt still has a ceiling, because some tasks are simply too big for one model call to handle reliably. The rest of this article is about getting past that ceiling.
Prompt chaining, also called sequential prompting, breaks a complex task into a series of smaller, manageable sub-tasks, each handled by its own dedicated prompt. The system then calls the model with each prompt in turn, and the output of one call becomes the input to the next, orchestrated in code.
Writing a short blog post about Sydney is a clean example. Step one prompts “generate 5 interesting topic ideas about Sydney” and returns a list. Step two takes that list and prompts “given these 5 topics, pick the most engaging one and write a 4-point outline”, returning a structured outline. Step three takes the outline and prompts “using this outline, write a 500-word blog post in a casual tone”, returning the finished piece. Each step is simple, focused, and far easier to get right than asking one prompt to produce a polished post in a single shot.
Chaining buys you the ability to build sophisticated workflows well beyond what one prompt can manage. It also introduces a new danger. Models can hallucinate, return the wrong format, or ignore an instruction, and an error in an early step propagates through everything downstream like a row of falling dominoes. Which is exactly why chaining alone is not enough.
Simply chaining prompts is not sufficient for a reliable system. You need validation between the steps, and that is what gate checks provide.
A gate check is a programmatic validation placed between steps in a chain, a quality-control point that confirms each intermediate output meets defined criteria before it is allowed to flow downstream. When a check passes, the chain continues. When it fails, the system has three options. It can raise an error and halt. It can retry the failed step. Or, best of all, it can retry the failed step while feeding the reason for the failure back into the prompt, which makes the retry far more likely to succeed.
In Python, the usual tool for this is Pydantic, the most popular data validation library in the language. It uses standard type hints to enforce that data has exactly the shape and types the system expects. Here is a gate check that validates a blog post the model has produced before the next step is allowed to touch it.
from pydantic import BaseModel, Field, ValidationErrorfrom typing import List
class BlogPost(BaseModel): title: str = Field(min_length=10, max_length=100) summary: str = Field(min_length=50, max_length=200) tags: List[str] = Field(min_length=3, max_length=10)
The check confirms the title is between 10 and 100 characters, the summary between 50 and 200, and at least three tags are present. Any failure triggers a structured retry instead of letting malformed data poison the rest of the chain. This small pattern, a schema plus a retry-with-feedback, is one of the highest-leverage ideas in the whole discipline.
Gate checks become essential the moment you remember ReAct. ReAct agents lean heavily on external tools, and external tools fail constantly. A weather API might return a rate-limit error, malformed JSON, a network timeout, or a payload missing the fields you expected. Without a gate check, the agent passes that broken observation straight into its next Thought, where it either crashes or spins off into confused reasoning.
The fix is to place a gate check between the Action and the Observation, validating the raw tool output against a schema and retrying in a controlled way when it fails.
from pydantic import BaseModel, Field, ValidationErrorfrom typing import Literalimport requests
Inside a ReAct loop, this changes everything. The model thinks, I need the weather for Melbourne, and calls the gated tool. On the first attempt the API returns a rate-limit error, the gate check fails because the response does not match the schema, and the system retries. On the second attempt the API returns a valid payload, the gate passes, and a clean, well-formed observation flows into the next Thought. The model reasons over good data and answers with confidence.
The point is that the reasoning chain only ever sees well-formed observations. Transient failures, rate limits, timeouts, schema drift, get absorbed by the retry rather than corrupting the workflow. This is the pattern that makes ReAct agents reliable enough for production, because in practice the external tools fail far more often than the model itself does.
Gate checks are reactive. They validate against fixed criteria and retry when something breaks. Feedback loops generalise that idea into something more powerful, where the model itself takes part in evaluating and revising its own work. This is the most advanced pattern in the progression, and it is where prompting starts to feel genuinely agentic.
Agents, with a model as their reasoning engine, can plan and act, but they are rarely perfect on the first try. A feedback loop lets the model receive feedback, reflect, and try again, improving its output across iterations until it meets the bar. The principle is the same as a student revising an essay after a teacher’s comments. A passive model waits for input and answers. An agent takes a goal, acts, observes the result, and iterates.
That feedback can come from three sources. The model’s own evaluation supports self-reflection. External validation applies automated checks and gate checks. User input brings a human into the loop for review and correction. Crucially, this gives the system a way to learn and correct itself within the task, with no retraining required.
Picture generating a customer apology email. In the first iteration the model writes a draft, and an evaluator, which could be a second model call or a rule-based checker, reviews the tone and reports “too casual for a corporate apology”. In the second iteration the model revises with that feedback in the prompt, and the evaluator responds “tone is better, but missing a clear call to action”. In the third iteration the model revises again, and the evaluator approves, tone and structure both meeting the criteria. The polished email goes to the user. Each pass tightens the output, and the loop has a cap so it cannot run forever.
Step back and the progression forms a single, coherent story.
At the foundation sits the model itself and the basic act of prompting, accessed either as a general model tuned to be helpful or as an API-based model split into system and user prompts.
On top of that sit the single-prompt techniques. Role-based prompting shapes who the model is. Chain of Thought shapes how it reasons. ReAct lets it reach into the world through tools. And prompt instruction refinement, tuning role, task, format, examples, and context, is the meta-skill that quietly improves all of them.
Above those sit the workflow patterns that turn a fragile prompt into a dependable system. Prompt chaining breaks big tasks into focused steps. Gate checks validate every step so one error cannot cascade. And feedback loops let the system evaluate and refine its own work until it meets the standard.
That arc, from a single clever instruction to a validated, self-correcting, multi-step system, is exactly the shift the industry is living through right now. The wording matters less than it used to because the models improved. What matters more than ever is the engineering around the model, the structure, the validation, the retries, the loops, that makes the difference between something that demos well and something you can actually trust to run thousands of times.
This piece covered the ideas. The interesting part is building them.
In the next article I take everything here and turn it into a real, working prompting engine in Python, a single task done reliably through a chain of focused prompts, Pydantic gate checks between every step, a gate-checked tool call that survives a flaky API, and a feedback loop that revises its own output until it passes. Theory becoming a system you can run, clone, and break.
If this was useful, follow along for part two, where the diagrams turn into code.
Written as part of an ongoing series on building dependable AI systems. The concepts here are the foundation. The engineering is where it gets fun.
Clever Prompts Are Cheap Now. Reliable LLM Prompting Systems Are the Skill. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.