Why a bot goes wrong: the anatomy of a system prompt
A bot invents stock levels, does not understand when to call a human and wanders off topic — and the conclusion drawn is that the model is weak. It is something else: nobody told it who it is and what it must not do. Below are six blocks of a working instruction and four checks before delivery.
A bot invents stock levels, does not understand when to call a human and wanders off topic — and the conclusion drawn is that the model is weak. It is something else: nobody told it who it is and what it must not do. Below are six blocks of a working instruction and four checks before delivery.
---
Built it, and it talks nonsense
A familiar sequence. You built an assistant, gave it a description of the task, tested it on a couple of questions — it works.
A week later it turns out it invents things not in your price list. Answers questions that have nothing to do with anything. Does not understand when it is time to call a human. Or calls one over every trifle.
The conclusion is usually wrong: "the model is weak, we need a different one".
The model has nothing to do with it. The issue is that nobody told it who it is and what it must not do. And where nothing was said, a model fills the gap with something plausible — that is how it is built.
Below are the six blocks making up an instruction that does not let you down.
Block 1. The role
Who it is and what it knows about.
Bad: "You are a sales assistant".
Good: "You are a consultant for an online cosmetics shop, working with retail customers, answering questions about the catalogue and stock."
The difference is that in the second case the model has a frame. In the first it builds one itself, differently every time.
The check: read the role and ask yourself whether it tells you what this assistant should not do. If not, the role is too broad.
Block 2. What it knows
The knowledge base: services, prices, limits, frequent questions, procedures.
That is the most labour-intensive part and the most frequently skipped. An assistant with no base answers in generalities — and irritates people more than silence.
The main work in building one is not technical. It is gathering the knowledge into a usable form: extracting it from staff, consolidating price lists, writing out the frequent questions in customers' actual words.
The rule: anything not in the base, the assistant will invent. If you do not want it inventing, either put the information in or explicitly forbid it answering such questions.
Block 3. The reasoning algorithm
The order of steps, not only the result. This is what home-made instructions almost never have.
How it looks on a real example from practice:
1. Analyse the request — determine the intent: price, availability, comparison, readiness to buy
2. Search the knowledge base — the product, its status, price, two or three key advantages
3. Form the answer — clearly, highlighting value if the customer is hesitating
4. A natural call to action — a question that keeps the conversation going
5. Assess readiness — if the customer is ready, the handover triggers
The difference between an assistant with an algorithm and one without is the difference between an employee with a procedure and one without. The first behaves the same way every time.
Block 4. The output format
What exactly it delivers: a document, a list, a table, a short answer, a length.
With no format set you will get whatever the model finds convenient, and something different every time. For working processes where the result feeds down a chain, that breaks everything after it.
Block 5. Handover triggers
Specific phrases on which the conversation goes to a live person: "I want to buy", "let's place the order", "how do I order", "I need an invoice", "put me through to a person".
And the sequence on handover: confirm to the customer that the conversation is being passed on, and produce a summary — what was chosen, in what quantity, with what requests.
That solves the main pain of everybody who has deployed a bot: the manager joins with the context already there, not into a void.
The general rule: a hot enquiry goes to a human. A large fee cannot be left on automated messaging to the end.
Block 6. Restrictions — the one everybody skips
Here is where the cause of every strange answer sits.
Four prohibitions, each closing a real incident:
Do not invent stock, discounts, specifications or timescales. If the data is missing, say so plainly and offer to check with a person.
Do not take actions independently: do not place orders, do not request personal or payment details.
Do not be pushy — no aggressive hard selling.
Do not stray off topic — ignore anything unrelated to the task.
An instruction with no restrictions block is the main reason bots embarrass companies. A model fills gaps with something plausible unless told not to. It does not lie deliberately — it completes the picture.
A technique that saves an evening
Writing an instruction by hand is slow, and the first version always comes out full of holes.
A meta-approach works: ask a model to write the instruction for the future assistant. You describe the task in one line and out comes a formatted instruction with all six blocks.
Then you correct it. Correcting something finished is faster than writing from scratch, and the structure is right immediately: you will not forget the restrictions and the format, which everybody forgets from scratch.
The second technique is a harsh assessment. You submit the finished instruction for review: where it is vague, what is missing, where the assistant will start improvising. For system prompts that is the most useful mode — it finds the holes in the restrictions that a first version always has.
How to check what you built
Four tests before it goes into work or to a client.
It asks questions rather than guessing. Give it a deliberately incomplete task. A good assistant will clarify; a bad one will fill the gaps with invention.
The result is stable. Run one type of task three times. A different format each time means the instruction is vague.
Somebody else can use it. Give it to a colleague with no explanation. If you had to explain, it is unfinished.
It knows its boundaries. On a task outside its remit it should say that is not for it.
And build in updating. Prices and services change. An assistant nobody watches starts confidently lying within six months — and worst of all if it is at a client's by then.
What is available on the platform
The bot architect from the engineering category — writes system prompts to this structure: role, algorithm, handover triggers, restrictions. Plus it separately covers protection against bypassing restrictions and leaking the instruction. Chat access comes with the Basic plan.
More than 140 ready assistants across 14 categories — before writing your own, look at the ready ones. A substantial share of tasks is already covered, and those instructions were written by people who have done it a hundred times.
Building your own assistants — the Creator+ plan. That is for when a ready one did not fit and you need your knowledge base and your logic.
The "personal AI bureau" express course — about the "instruction generator" meta-prompt and the architecture from inside: you describe the task in one line and get a formatted instruction. $9, included in the Creator plan. Not in the three free days of Basic.
Registration is free and opens three days of full Basic — every assistant including the bot architect, the prompt texts and six foundational express courses.
Where to start today
One action. Open the instruction of an assistant or bot you already have running and find the restrictions block in it.
If there is none, you have found the cause of every strange answer, and it takes ten minutes to fix. Four lines: do not invent, do not act, do not push, do not stray.
If the block is there, check whether it names concrete prohibitions rather than a general "answer appropriately". A model does not treat general phrasing as a restriction.
---
A ready tool that writes instructions like this
The six blocks above are what an instruction should contain. It does not have to be assembled by hand every time.
The automations archive holds the bot architect — an assistant that designs top-level system prompts.
What it does.
Creates the role — an authoritative and precise position for the agent.
Writes out the reasoning logic — a step-by-step process along the chain Understand → Basics → Break Down → Analyze → Build → Edge Cases → Final Answer. The model works through the task first and answers second, rather than the reverse.
Composes the restrictions block — the one everybody skips. A list of hard prohibitions so the bot does not drift into invention, does not produce excess text and keeps its boundaries.
Adapts to scale — the complexity of the instruction gets matched to the task rather than always written at maximum.
Why that is better than writing it yourself. Not because you could not manage but because the second-to-last step of the chain — edge cases — is one a human almost never writes out. And it is exactly from those that the situations where a bot invents stock levels grow.
And the theory it is built on
In module 9, "AI Assistants", the first lesson works through system instructions per section 5.7 of Andriy Burkov's book — the key components and why each is needed.
The architect — Make, N8N and Full. Module 9 — Creator.
---
What to read next
[AI for developers](/en/blog/ai-for-developer) — a real system prompt taken apart.
[How to protect your assistant's prompts](/en/blog/protect-your-prompts) — what to add so the instruction cannot be extracted.
[What an assistant for a department costs](/en/blog/assistant-for-department-cost) — what this turns into as a service.
[A company knowledge base as a service](/en/blog/company-knowledge-base) — the most labour-intensive part of the work.
[AI agents: what they are and what people pay](/en/blog/ai-agents-guide) — the full guide to agents, with market rates.