Most people building an agent start at the system prompt. They open a blank box and write paragraphs of instructions. Then they add more paragraphs when it misbehaves. By week two the prompt is 2,000 words of pleading and the agent still does the wrong thing.
We tune the system prompt last. It is the cheapest knob and the weakest one. Here is the order we actually work in, and why prompt wording comes at the end.
The system prompt is not where the bug lives
When an agent fails, the prompt is the obvious suspect. It is rarely the culprit. The real failures cluster in three places, and none of them are wording.
First, the tools are wrong. The agent calls an API that returns ambiguous data, or it has no tool for the thing you asked. Second, the context is wrong. The agent never saw the document it needed, or it saw ten irrelevant ones. Third, the data is wrong. The source of truth disagrees with itself, so any answer is defensible and none is right.
You cannot prompt your way out of a missing tool. You can write "always check the order status" a hundred ways, but if there is no clean order-status tool, the agent will guess. So we fix the plumbing before we touch the words.
The order we work in
We build agents in roughly this sequence. Each stage closes off a class of failure before the next one starts.
1. Define the job in one sentence. Not the persona, the job. "Answer customer questions about order status and returns using our order system." If we cannot write that sentence, the agent is not ready to build.
2. Wire the tools. This is most of the work. Each tool gets a tight schema, a clear name, and a description the model can act on. We make the tools return clean, typed data, not raw JSON blobs. A good tool layer makes the prompt short.
3. Get the context right. For a RAG agent, this is retrieval quality. We measure whether the right chunks come back before we worry about how the model phrases the answer. Bad retrieval looks like a prompt problem and is not.
4. Fix the data. If two systems disagree on a customer's status, we resolve that at the source. An agent reading conflicting data produces confident nonsense.
5. Now tune the system prompt. By this point the prompt is short. It sets the role, names the tools, states the hard rules, and defines what to do when it does not know. That is usually under 400 words.
What actually goes in the prompt
A good system prompt does four things and stops. It names the role and scope. It tells the agent which tools to prefer and when. It lists the non-negotiable rules, like "never invent an order number." And it defines the failure path: what to say when the answer is not in the data.
The failure path matters most. An agent that says "I do not have that, here is how to reach a human" beats an agent that guesses. We write that line carefully and test it hard.
We keep the prompt short on purpose. Long prompts compete with themselves. Rule twelve contradicts rule three, and the model picks whichever it noticed last. Short prompts are easier to test and easier to debug when something breaks in production.
Why this saves you money
Teams that start at the prompt burn weeks rewriting paragraphs and never touch the real bug. The agent stays unreliable, so it never ships. We have put 10 production products into the world in 7 months as a 2-person team partly because we refuse to debug the wrong layer.
The payoff is real when the plumbing is right. A support agent we built answers in 12 minutes, down from 4 hours. That number comes from clean tools and good context, not from a clever prompt. The prompt is the last 10 percent, and it only works because the first 90 percent is solid.
This is the work behind an OpenClaw Installation or a RAG Chatbot build. Fixed price every time. You own the code. We exit when it works, and you are not locked in.
If you are staring at a 2,000-word prompt that still misbehaves, the prompt is probably not the problem. Book a free 30-minute call and we will tell you which layer to fix first.