Beyond one-off prompts: how to write robust system instructions
You send a request to the AI and get a good response. The next day, you make the same request and get a different result: longer, less precise or with a made-up fact. If this happens often, the problem isn't how you ask. It's that you rely on one-off prompts you write from scratch every time.
In this chapter, we move from the legal framework to hands-on design. You'll see why prompt engineering tricks aren't enough to build reliable systems and how to structure a system instruction in five blocks. You'll also find a complete contract review example and two techniques for refining the results.
Why prompt tricks aren't enough
When generative AI became popular, prompt engineering was often sold as a collection of tricks: magic formulas, secret keywords or phrases that supposedly “unlock” better responses.
This ad hoc approach has three problems when you want to use it in a business:
- It's inconsistent. A trick that works with one model may not work with another, or even with the next version of the same model.
- It becomes chaotic. You keep adding instructions as you go, with no clear order, and eventually some contradict each other.
- It requires you to always be present. Every result requires you to write a new request. You're still selling your time, as we saw in chapter 7 on superficial productivity.
To build systems that produce repeatable, scalable results, you need to move from improvised prompts to system instructions (or system prompts), which we'll also call operational directives here.
A system instruction isn't a suggestion. It acts as an agent's source code in natural language. It defines who the agent is, the limits of its scope, how it should reason and what form its output should take.
Anatomy of a system instruction: the R-C-M-F-E framework
For an agent to work consistently, predictably and safely, organise its system instruction into five blocks:
Block
What it defines
Question it answers
R · Role and stance
Who the agent is, its tone and its attitude towards evidence
What perspective does it bring to the problem?
C · Context and scope
Why it exists, who it works for and what data it receives
What problem does it solve?
M · Methodology
The process it follows, step by step
How does it arrive at the answer?
F · Safeguards
What it must never do
Where are its limits?
E · Output structure
The exact structure of the result
What form does its output take?
Block 1: role and stance towards evidence
This block defines the agent's area of competence and how cautious it should be in making judgements. A good role isn't there to flatter the model. It's there to calibrate how it reasons.
Bad practice:
“You are a world-class marketing expert and you know everything.”
This kind of phrase pushes the model to sound grandiose and overconfident.
Good practice:
“You are an analytical auditor specialising in evaluating B2B business models. Your stance is sceptical, constructive and rigorous. You value evidence more than rhetorical claims. If the data is insufficient, state this explicitly.”
The difference is that the second role tells the agent how to handle uncertainty, not just how much it knows.
Block 2: context and scope
Here you define the environment in which the agent works. Include:
- Who will use it: an operations team, an end customer, another agent.
- What it will receive as input: attachments, transcripts, data in JSON format, emails.
- What its specific goal is. The point isn't to generate lots of text, but to resolve a specific bottleneck.
The clearer the scope, the less the model will have to guess.
Block 3: reasoning methodology
This block requires the model to follow a phased process before giving an answer. It's the step-by-step reasoning technique (chain of thought) we saw in chapter 2, but applied in a structured way.
Example:
- Extract the facts. Identify the data and claims in the input.
- Cross-check them against the Brain. Check whether they match the internal manuals.
- Identify discrepancies or risks.
- Write the proposal using the specified structure.
This reduces logical leaps and also lets you review which phase the agent got wrong if something goes awry.
Block 4: safeguards and constraints
Models tend to be overly agreeable: they try to please and always provide some kind of answer, even when they have no data. Constraints act as a firewall against this behaviour.
Some useful examples:
- “Do not invent sources, statutory provisions, metrics or case law.”
- “If the information is not in the Brain, respond exactly: "Information not available in the authorised sources".”
- “Do not use polite introductions or sign-offs. Start directly with the analysis.”
- “Do not make final decisions on the user's behalf. Present options with their risks.”
Two tips to make them work better:
- Explain what to do instead of what is prohibited. “Do not invent” works better alongside “if you don't know, write this specific sentence”.
- Don't pile up prohibitions without any order. Group them and prioritise those that genuinely protect the user.
Block 5: output structure
This block removes any ambiguity about the format. It's a contract: the agent knows exactly what it has to deliver.
You can specify:
- Exact Markdown headings.
- Tables with defined columns.
- Structured data formats, such as JSON or YAML, if another program or agent will read the result.
Consistent output serves two audiences: the person who reads it effortlessly and the software that processes it without errors.
Example: from an improvised prompt to a system instruction
The improvised prompt
“Review this contract and tell me if it's OK. Find the flaws and give me a summary in a table.”
Typical result: different responses every time, important clauses overlooked, invented risks and a length that varies from one day to the next.
The system instruction
Two techniques for refining your system instructions
1. Include examples (few-shot prompting)
Add one or two complete examples to the system instruction: a real input and the exact output you expect. A concrete example usually guides the model much better than any abstract description of the result.
To make the most of this:
- Use representative examples, similar to the real cases the agent will receive.
- Vary them if you add more than one. If they are all too similar, the model will tend to copy specific details rather than pick up the pattern.
- Remove personal or confidential data from the examples.
2. Split into modules
Don't burden a single agent with ten pages of instructions to handle the entire business. The longer and more scattered an instruction is, the easier it is for the model to lose parts along the way. This is the context degradation we saw in chapter 1.
It's better to create several agents with short instructions, each focused on a single phase of the process. For example:
- One agent extracts the contract clauses.
- Another compares them with company policy.
- A third writes the final report.
It's the same orchestration logic we saw in chapters 3 and 4: small, predictable pieces that are easy to review.
A limitation worth remembering
A good system instruction greatly reduces errors, but doesn't eliminate them. The model still operates on probabilities. In addition, a malicious input can try to bypass the instructions through the prompt injection we saw in the previous chapter.
That's why you should always combine your instructions with:
- Deterministic validation for critical data, such as calculations, dates or formats.
- Human review of consequential decisions.
- Regular testing with real cases whenever you change model or version.
Quick checklist for reviewing your system instructions
Before launching an agent, check that its instruction:
- Defines a role with a clear stance towards uncertainty.
- Explains who uses it, what data it receives and what problem it solves.
- Specifies the authorised sources and what to do if information is missing.
- Describes the process in numbered steps.
- Includes specific constraints and an alternative for each one.
- Sets an exact output format.
- Leaves room for human decisions.
- Has been tested with several real cases, including difficult ones.
Conclusion
A one-off prompt solves a task. A well-designed system instruction creates an agent that solves that task the same way every time. By structuring your directives with a role, context, methodology, constraints and output format, you turn the way you work into something reusable, reviewable and scalable. That's the step that lets you stop depending on your presence in every interaction.
Want to start turning your working method into agents with clear instructions? Visit libertadia.com and sign up in the app.