Okay I need to say something that might sting a little.
If you have been using Claude and thinking "this model is decent but sometimes it just does not get what I am asking," there is a very good chance the problem is not Claude. The problem is how you are structuring your prompts. And there is one specific thing you are almost certainly not doing that would fix most of that frustration immediately.
You are not using XML tags. And I genuinely do not understand why nobody talks about this more because the difference is not subtle. It is obvious. It is the kind of thing where you try it once and then go back and look at every prompt you have ever written and feel mildly embarrassed.
Let me show you what I mean
Right now, most people write prompts like this. A paragraph explaining the context. Then some instructions. Then maybe an example of what they want. Then the actual content they want processed. All of it smooshed together into one continuous block of text that the model has to read and interpret and somehow figure out which part is the task, which part is background, which part is a constraint, and which part is the thing you actually want it to work on.
And then you wonder why it sometimes focuses on the wrong thing, or ignores a constraint you mentioned, or treats an example as if it were the main input.
Here is the thing. The model is not psychic. It is reading your prompt the same way a person would read a wall of text with no formatting and no clear structure. It is making its best guess about what each part means. Most of the time it guesses right. But most of the time is not good enough when you actually need consistent, reliable outputs.
XML tags fix this by making the structure of your prompt explicit instead of implicit. You stop hoping the model figures out that one section is context and another is instructions. You just tell it directly by wrapping each part in a labeled tag.
It looks like this. Your document goes inside a tag called document. Your instructions go inside a tag called instructions. Your example goes inside a tag called example. Your constraints go inside a tag called constraints. Now the model does not have to guess what each part is doing. You told it. Clearly. Unambiguously. In a format it was specifically trained to recognize and respond to.
Why this works so well with Claude specifically
This is not just a general prompting tip that applies equally to every model. Claude has been specifically trained to pay close attention to XML structure in prompts and to treat the contents of different tags according to their labels. Anthropic built this in intentionally because they found it produced more reliable behavior on complex tasks.
What that means in practice is that when you put your instructions inside an instructions tag and your document inside a document tag, Claude treats those two things differently in a way that actually reflects what you intended. It knows the instructions are what it should do. It knows the document is what it should do it to. That distinction sounds obvious but it is surprisingly easy to blur when everything is written as prose.
According to Anthropic's own prompt engineering documentation, XML tags are one of their top recommendations for getting better results from Claude, and the reason they give is exactly this: the tags reduce ambiguity in a way that directly improves how reliably the model follows your intent.
If Anthropic is telling you to do this and you are not doing it, that is worth thinking about.
The situations where this makes the most dramatic difference
There are a few specific cases where switching to XML tags goes from nice improvement to genuinely transformative.
The first is when your prompt is long. Once your prompt gets beyond a few paragraphs, the chance that the model loses track of something or misinterprets the relationship between different sections goes up significantly. Tags act like signposts. No matter how long the prompt is, the model always knows exactly what each section is.
The second is when the content you are processing contains text that could be confused with instructions. This is a real and common problem. If you ask Claude to analyze a document and that document happens to contain phrases like "please summarize" or "ignore the above" or "your task is to," things can get weird fast without clear structure separating the content from the instructions. With tags, the model knows that what is inside the document tag is content to be analyzed, not commands to be followed.
The third is when you are doing something where consistency matters across many different inputs. If you are building something where the same prompt structure gets used with many different pieces of content, tags make the outputs dramatically more consistent because the model always interprets the structure the same way regardless of what is in the content itself.
The "but modern models are smart enough" counterargument
I know what some people are thinking. Claude is a very capable model. It can figure out prompt structure without explicit tags. Why add the overhead?
Here is my honest take on that. Yes, Claude is good at interpreting unstructured prompts. For simple two-sentence prompts it honestly does not matter. But the people who most need this advice are not writing two-sentence prompts. They are writing complex multi-part prompts with lots of context and lots of instructions and lots of content, and those are exactly the cases where even a very capable model benefits from explicit structure.
The overhead of adding XML tags to a prompt is maybe thirty seconds of your time. The benefit is more consistent, more accurate, better-structured outputs on anything that is even slightly complex. That trade is so obviously in your favor that the only reason not to do it is not knowing about it.
Now you know about it. So.
How to start without overthinking it
Do not try to tag every single part of every prompt at once. Start with the one structural distinction that matters most in whatever you are working on, which is almost always the separation between your instructions and the content you want processed.
If you are sending a document for analysis, wrap the document in a document tag and your instructions in an instructions tag. That one change alone will improve your results on most complex tasks. From there you can add more tags as you see fit, context for background information, example for reference outputs, constraints for things the model should or should not do.
Keep the tag names obvious and descriptive. The model reads the tag names and uses them to understand what the content inside is for, so instructions tells it more than section2. Use names that would make sense to a human reader because they will make sense to the model too.
Once you start doing this you will notice something else. Forcing yourself to tag the components of your prompt forces you to think more clearly about what those components actually are. A lot of vague prompts are vague because the person writing them was not totally clear in their own head about what they were asking for. The tagging process surfaces that ambiguity before you send the prompt, which means you fix it before it causes a bad response instead of after.
The Prompt Toolbox is a good place to test your prompts and measure how your changes are affecting things, including token counts which matter if you are using the API and paying per token.
The real point
Prompt engineering has a reputation for being complicated and technical and full of obscure techniques with academic-sounding names. Most of it is not. Most of it is just being clearer about what you want. XML tags are the clearest possible example of that. You are not doing anything fancy. You are just labeling your content so the model does not have to guess what it is.
Try it on the next complex prompt you write. If you do not notice a difference I will be genuinely surprised.