> ## Documentation Index
> Fetch the complete documentation index at: https://help.pantaos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Structured Prompts

> How to organize long prompts with XML tags, JSON contracts, and a clean system prompt anatomy.

## Why Structure Matters

The longer a prompt gets, the more important its structure becomes. A 200 token prompt can be unstructured and still work. A 2000 token prompt with mixed instructions, context, examples, and input is almost guaranteed to underperform unless its parts are clearly delimited.

Structure does three things at once. It makes the prompt parseable for the model, so it can distinguish instructions from data. It makes the prompt readable for your team, so you can maintain it over time. And it makes the output parseable for your code, so you can extract the result reliably.

Inside PANTA OS, every assistant has a system prompt that benefits from the structure described on this page. The longer the system prompt, the more important the structure.

## XML Tags

XML tags are the most flexible structuring tool because they can be nested, named freely, and parsed easily. Most modern models have been trained extensively on XML tagged prompts and respond particularly well to them.

There is no canonical set of tag names. Pick names that describe what they contain, and use them consistently across your prompts.

```text theme={"theme":"github-dark"}
<role>
You are a technical writer producing API reference documentation.
</role>

<style_guide>
- Use sentence case for headings.
- Use the imperative mood for descriptions.
- Never include marketing language.
</style_guide>

<input>
{api_specification}
</input>

<task>
Produce reference documentation for the API in the input. For each endpoint, include
the HTTP method, path, parameters, and a one paragraph description.
</task>

<output_format>
Return Markdown with one H2 heading per endpoint.
</output_format>
```

The pattern: one tag per logical section, names that match what the section contains, and the input clearly separated from the instructions. The model can now parse this prompt as five distinct components instead of one undifferentiated wall of text.

A few rules of thumb:

* **Use consistent tag names.** If you call something `<context>` once, do not call it `<background>` later. Consistency reduces the chance of misinterpretation.
* **Nest where the structure has a natural hierarchy.** Multiple documents go inside a `<documents>` tag, each as a `<document>` with an index attribute.
* **Refer to tags by name in your instructions.** "Using the contract in the `<contract>` tags above, identify ..." is clearer than "Using the contract above, identify ...".

## JSON Output Contracts

When the output will be parsed by code, define the schema in the prompt. There are three ways to do this, in increasing order of reliability.

The first is a description of the schema in prose:

```text theme={"theme":"github-dark"}
Return a JSON object with the keys "company" (string), "amount" (number), and
"due_date" (ISO 8601 date string).
```

The second is a JSON schema or example:

```text theme={"theme":"github-dark"}
Return a JSON object matching this schema:

{
  "company": "string",
  "amount": "number",
  "due_date": "YYYY-MM-DD"
}

Use null for any field that cannot be determined from the input.
```

The third, and most reliable, is to use the structured output features of the API: response format constraints or tool use with a defined schema. These features force the model's output to validate against a JSON schema before it is returned. They are the right answer for any production pipeline that consumes JSON.

Even with structured output features enabled, keep the schema description in the prompt. The features constrain the shape; the prompt explains the meaning. Both matter.

## System Prompt Anatomy

The system prompt is the place to put everything that should hold for the entire conversation: the role, the rules, the constraints, the format expectations. A clean system prompt has roughly six sections, in this order:

1. **Role and identity.** Who the assistant is, what their expertise is, and who they are talking to.
2. **Core responsibilities.** The tasks the assistant is expected to perform.
3. **Behavior rules.** How the assistant should communicate: tone, formality, length, language.
4. **Constraints and refusals.** What the assistant must not do, and what to do when asked.
5. **Output format.** The default format for responses.
6. **Examples (optional).** Two or three short interactions that demonstrate the rules.

A worked example for a customer support assistant:

```text theme={"theme":"github-dark"}
## Role and identity
You are the support assistant for ACME Software, a B2B inventory management platform.
You help customers diagnose and resolve issues with the product. You speak with
technical accuracy and avoid jargon when a plain word will do.

## Core responsibilities
- Answer questions about how to use the product.
- Diagnose error messages and suggest fixes.
- Escalate to a human agent when you cannot resolve the issue in three exchanges.

## Behavior rules
- Reply in the language of the customer's most recent message.
- Use second person, address the customer directly.
- Keep responses under 150 words unless a step by step procedure is required.
- Cite the relevant section of the documentation when one exists.

## Constraints
- Do not invent product features. If you are unsure whether a feature exists, say so.
- Do not discuss pricing, contracts, or roadmap items. Direct those questions to sales.
- If the customer becomes abusive, end the conversation politely and escalate.

## Output format
Plain text. No markdown headings. Code or commands inside fenced blocks.

## Examples
[two short example interactions]
```

This structure is not magic, but it covers the ground. Assistants built this way are easier to update, because each kind of change has an obvious place to go. The system prompts generated by the PANTA OS Assistant Wizard follow this skeleton, and the manual creator gives you the same scaffolding to fill in by hand.

## Order of Elements

Within a prompt, order matters more than people expect. Recency bias in models is well documented: instructions placed at the very end of a prompt tend to be followed more reliably than instructions placed in the middle.

A few practical guidelines:

* **Put the role and core rules at the top.** They define the frame.
* **Put long context in the middle.** Documents, transcripts, examples.
* **Put the immediate task at the end.** "Now, given the document above, produce ..." should be the last thing the model reads before it generates.

For long prompts that include both system instructions and user instructions, repeat critical constraints at both the top and the bottom. The redundancy is cheap and the reliability gain is real.

## Delimiters for input

Always delimit the input clearly. The most common choices, in order of preference:

* **XML tags.** `<document>...</document>`. The most flexible and best supported across modern models.
* **Triple backticks.** `...`. Standard for code and unstructured text.
* **Triple quotes.** `"""..."""`. The classic delimiter, still works.
* **Markdown headings.** `# Document` followed by the content. Less precise but readable.

The wrong choice is no delimiter at all. When user input is concatenated directly into a prompt without delimiters, the model sometimes treats the input as additional instructions, which is both an output quality issue and a security issue (prompt injection).

## A Complete Structured Prompt

Putting it all together for a realistic task:

```text theme={"theme":"github-dark"}
<role>
You are a senior research analyst producing executive summaries for a board of
directors. Your audience is non technical, time constrained, and decision oriented.
</role>

<task>
Read the report in the <report> tags and produce an executive summary.
</task>

<style_guide>
- Length: 250 to 300 words.
- Open with the single most important finding.
- Use plain English. Define any acronym on first use.
- Quantify wherever possible. Replace "significant" with the number.
- Do not editorialize. State what the report says, not what you think.
</style_guide>

<output_format>
Return your response inside <summary> tags. Inside, use three sections separated
by blank lines: Headline (one sentence), Findings (one paragraph), Implications
(one paragraph). Do not include the section labels in the output.
</output_format>

<report>
{report}
</report>

Now produce the summary, following the style guide and output format above.
```

Every section is named, the input is clearly delimited, the output contract is precise, and the final instruction is at the end where the model will weight it most. This structure scales: the same skeleton works for prompts of 500 tokens or 5000 tokens.

## What Comes Next

Strong structure prevents most failures. The remaining failures, the ones where the model produces confident but wrong output, are addressed in Reducing Hallucinations.