Role, Negative and Structured-Output Prompting
Giving a model a role, telling it what to avoid, and getting output your code can rely on — JSON, schemas and delimiters.
IntermediateVerdeshell Team · 8 min read · Last reviewed
A role shapes tone and focus but adds no knowledge. Negative instructions work better rewritten as what to do instead. And when code reads the answer, ask for a strict structure — then validate it, or use a feature that enforces the schema.
Key takeaways
- Role prompting sets who the model is acting as; it shapes tone and focus but does not add knowledge.
- Negative prompting tells a model what to avoid — but “do X” usually works better than “don’t do Y”.
- Structured-output prompting asks for a fixed format such as JSON; features that enforce a schema are more reliable than asking.
- Separate instructions from data with delimiters or tags, and put long documents before the question.
Role prompting
Role prompting sets who the model is acting as, usually in the system prompt: a support agent for a software product, a reviewer checking contracts for one specific risk, an editor for a technical audience. Anthropic’s guidance notes that even a single sentence of role makes a difference.
System: You are a support specialist for an HR software product. You answer
questions from HR managers in India about payroll features. Be concise and
practical, and say plainly when something is not supported.A role changes vocabulary, depth, tone and what the model treats as relevant. What it does not do is add knowledge. “You are a world-class tax expert” does not make the model know your tax rules — supply the rules. The useful part of a role is usually the audience and the purpose, not the flattering job title.
Negative prompting
Negative prompting means telling the model what not to do. The term comes from image generation, where tools offer a separate “negative prompt” field listing things to keep out of the picture. With language models it usually just means instructions such as “do not use jargon” or “don’t mention pricing”.
These often work less well than you would expect. Anthropic’s guidance is to tell the model what to do instead of what not to do: “write in plain English a new customer would understand” gives the model a target, where “no jargon” only names the thing to avoid — and mentioning it keeps it in the context.
Keep genuinely hard constraints — never reveal a customer’s data, never quote a price — as explicit rules, and enforce them in code where you can. A prompt is a strong suggestion, not a guarantee.
Structured-output prompting
When code will read the answer, ask for a fixed structure — JSON with named fields, a fixed set of labels, XML tags around each part — and include an example of the exact shape.
Extract the following from the invoice below and reply with JSON only:
{"supplier": string, "invoice_number": string, "total": number, "due_date": "YYYY-MM-DD"}
If a field is missing, use null.Asking is not the same as guaranteeing. Some APIs now enforce it: OpenAI’s Structured Outputs feature guarantees the response matches a supplied JSON schema, where its older JSON mode only guaranteed valid JSON. Where a model offers schema enforcement or tool calling, prefer it. Where it does not, validate every response and retry on failure.
One older technique is fading: prefilling the start of the model’s reply (an opening brace, for example) to force a format. Anthropic no longer supports prefilled responses on its newer models and recommends direct instructions or structured outputs instead.
Delimiters and document placement
Separate the instruction from the material it applies to — with headings, triple quotes or XML-style tags such as <document> and <instructions>. It stops the model confusing text it should act on with text it should only read, and it makes long prompts maintainable.
Placement matters with long inputs. Anthropic’s guidance is to put long documents near the top of the prompt, above the question and instructions. Combined with clear tags, it is one of the cheapest improvements for document-heavy tasks.
Putting them together
A typical production prompt uses all of these: a role and audience in the system prompt, the documents in tags at the top, the task stated positively, one example of the exact output shape, and a schema the API enforces. Each part earns its place by measurably improving results on real inputs — the discipline described in what is prompt engineering.
Want this built properly?
We design and build AI systems for clients. Tell us the problem and we will tell you honestly whether AI — and which kind — is the right fit for it.