Ask a team what they changed the last time their agent got noticeably better and you will usually hear about the prompt. Ask what they changed the last time it got noticeably worse and you will hear about the prompt again. The prompt is the thing everyone can see, so it absorbs the credit and the blame.
Underneath, the more powerful lever is usually the set of examples the system has been shown: what a correct output looks like here, what an incorrect one looks like, and what happens at the edges. That set is an asset. Most teams do not treat it like one.
Why examples do work prompts cannot
A prompt describes the task in the abstract. An example demonstrates the task in your organisation, with your document types, your terminology and your standard of good.
Consider "summarise the mandatory requirements". Every word in that instruction is contested in practice. Mandatory according to which section. Requirements at what level of granularity. Summarise into what shape, for whom to read. You can keep adding qualifiers to the prompt and you will keep discovering new ambiguities, because the ambiguity is in the domain, not in the sentence.
Three real examples settle all of it in a way no amount of prose can. This is what came in, this is what went out, and this is what the reviewer accepted.
The balance problem
More examples is not automatically better, and this is where teams get caught.
Too few, and the model concludes there is essentially one way to do the task. It performs beautifully on anything resembling the examples and falls apart on the first document that is structured differently, which in tender work is roughly every second document.
Too many of the wrong kind is the more insidious failure. If you feed a system a hundred real proposal drafts scraped from a shared drive, you have taught it your organisation's bad habits along with the good ones: the padding, the unsupported claims, the sections everyone copies forward without reading. It will reproduce them fluently. The output will look more like yours the worse it gets, which makes the problem very hard to see in review.
The useful library is curated, not collected. Someone decided what belongs in it.
What a real example library holds
For a tender compliance agent, the library is not one folder of good outputs. It is five kinds of thing, and the last two are the ones people skip.
Accepted outputs. A compliance matrix that a bid lead signed off, alongside the pack it came from.
Corrected outputs. The first draft, the corrected version, and ideally a line on what was wrong. This pair is worth more than either half alone, because it shows the shape of the error rather than just the destination.
Edge cases. The pack with the scanned annexure. The one where the deadline is stated twice and inconsistently. The department whose template puts mandatory items in an appendix.
Rejected outputs. Work that was wrong enough not to use, kept deliberately, with the reason recorded. This is the material that teaches the boundary.
Anti-patterns. Outputs that look right and are not: a matrix that is well-formatted and confidently cites a clause that does not exist. Any team that has run a RAG system for a while has a collection of these, usually in a chat thread somewhere.
The rejected and anti-pattern categories are what stop the library becoming a machine for reproducing your average work.
Where the examples come from
The honest answer is that they come from human review, which is why the loop in the first diagram closes back on the library. Every correction a reviewer makes is a candidate example, and the cheapest possible way to build a library is to capture corrections at the moment they happen rather than reconstructing them later.
This has a practical consequence for how you build the review step. If a reviewer can reject an output but cannot say why, you have collected a signal and thrown away the data. A small set of reason codes — wrong source, requirement missed, wrong format, overstated certainty, out of scope — turns each rejection into something that can be routed and reused. That mechanism is the subject of the article on human correction loops.
Maintenance, which is the part nobody plans for
An example library decays. Templates change, evaluation criteria change, the organisation's own standard of good moves. An example from two years ago may now be teaching the system something that is no longer true.
Treat it like any other governed dataset. Each example has an owner, a date and a source. There is a review cycle, even if it is only annual. When a domain rule changes, someone goes and looks at which examples that rule touches. And the library is versioned alongside the eval set, so that "we improved the examples" is a change that can be tested rather than asserted.
That last point matters more than it sounds. Adding examples is a change to the system's behaviour. It deserves the same treatment as changing the prompt or the model: run the evals before and after, and know what moved. We cover that in continuous evals.
What good looks like
A library with five categories, not one folder of good work.
Corrections captured as pairs, with a reason, at the moment they happen.
An owner, a date and a source on every example.
A review cycle that catches examples the domain has outgrown.
Evals run before and after any change to the library, so improvement is demonstrated rather than assumed.
Practical checklist
- Create the five categories before you start collecting
- Capture the before-and-after pair, not just the corrected version
- Add a small fixed set of rejection reasons to your review step
- Deliberately keep rejected outputs and confident-but-wrong ones
- Put a name and a date on every example
- Re-run evals whenever the library changes
How CloudNala can help
The first version of an example library usually already exists, scattered across email threads, review comments and someone's folder of "good ones". A short piece of work to consolidate it, categorise it and put an owner on it tends to improve agent quality faster than anything done to the prompt. After that the useful work is structural: making the review step capture reasons, and wiring the library into the eval set so changes to it can be tested rather than hoped about.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za