LLM Ops: Keeping It Working
Building it is day one. This is every day after.
LLM Ops is the loop you run after your AI system is live: record what happened, check if it was good, work out why it broke, fix it, and ship the fix safely.
Why this exists
An AI system is not finished when it works once. The questions people ask change. Documents go stale. Someone edits a prompt. A tool starts failing quietly. Nothing announces itself.
LLM Ops is the routine that catches all of that. It is unglamorous and it is the difference between a demo and something people can rely on.
The loop
- Trace. Record every run. One record per run, so nothing is invisible later.
- Evaluate. Score the answers. Was it actually good, or did it just sound good?
- Diagnose. When a score drops, find out where and why. Was it the search, a tool, or the instructions?
- Gate. Try the fix against your saved test set. If the score does not improve, it does not ship. This is the step people skip.
- Release. Ship the change: a new prompt version, a setting, a tool fix. Write down what you changed so you can undo it.
Then it starts again, because the fix you just shipped is now the thing being watched.
What actually gets changed
- The prompt or instructions, which is the most common fix by a long way
- Which documents are searched, and how many pieces come back
- The tools, when one is failing or returning something unexpected
- The model or its settings, which is a bigger change than it looks and needs the gate most
- The guardrails, when it did something it should have refused to do
The three questions this answers
| Question | The step that answers it |
|---|---|
| What happened? | Trace |
| Was it any good? | Eval |
| Did my fix actually help? | Gate |
The freelancer version
You do not need software for this. If you run a prompt for client work, the whole loop fits in a document:
- Keep the last few real inputs and outputs. That is your trace.
- Keep five real examples with what a good answer looks like. That is your eval.
- When a client complains, add their case to the five.
- Before you change the prompt, run the five. After you change it, run them again.
- Keep the old prompt in the same file with a date, so you can go back.
That is real LLM Ops. The tools people pay for do the same five things at a scale a document cannot handle.
The mistake that costs most
Editing a live prompt directly, with no copy of the old one and no test. It feels fast. Then something is worse a week later, nobody remembers what changed, and there is nothing to roll back to. Keep the old version. Always.
More words
- Prompt Engineering
Writing the instruction so the answer comes back right
- Context Engineering
Choosing what the AI gets to see while it answers
- Loop Engineering
Teaching an AI to check on its own, no prompt needed