XML Prompting: Structured Output for Complex Tasks

What XML prompting is and why it exists

Most operators who have worked with JSON output prompting hit a wall at the same spot: the task requires deeply nested structures, multiple files worth of code, or output that mixes content with metadata. JSON handles flat data extraction well. But when your output needs to represent hierarchical relationships and feed directly into automated parsing, you need a different format.

XML (Extensible Markup Language) is a structured output format where you define your own tag names. Unlike JSON's generic keys and brackets, XML uses opening and closing tags that you name to match their purpose. A tag called path> tells both the model and your parser exactly what that data represents. A tag called changes> wraps related output in a named container that can be parsed, validated, and routed programmatically.

The practical difference for client engagements. When you're prompting a model to generate code across multiple files, track which files changed, or orchestrate multi-step agent workflows, XML gives you explicit semantic structure that survives complex nesting. JSON at the same depth becomes a maze of brackets where a single missing comma breaks the entire document.

Here is the key distinction: JSON is a data exchange format. XML is a document markup format. That difference matters when your output looks more like a structured document (code changes, agent task plans, nested configuration) than a data record (contacts, flights, inventory).

> When to reach for XML: Your AI output contains code that needs to be extracted and written to files. You need to track operations (create, update, delete) alongside file content. Your output has three or more levels of nesting. The output will be parsed by an automated system, not read by a human.

XML basics for non-developers

XML follows one core pattern: everything lives inside named tags that open and close. If you've ever looked at HTML, you already recognize the structure.

<client_report>
  <client_name>Acme Corp</client_name>
  <quarter>Q1 2026</quarter>
  <status>On track</status>
</client_report>

Three rules govern all XML:

• Every opening tag needs a closing tag. must be followed by . Miss the closing tag and the entire document breaks.
• Tags nest inside each other. A report> tag can contain name>, , and tags. The inner tags must close before the outer tag closes.
• Tag names are semantic. You pick names that describe the content. path> is better than . changes> is better than . The model reads these names as instructions for what to put inside them.

That's the entire syntax you need. You don't need to learn XML schemas, DTDs, or namespaces. You need to understand the open-nest-close pattern well enough to write a template the model can fill in.

Attributes add metadata without adding nesting. A tag can carry extra information inside its opening bracket:

<file file_operation="UPDATE">
  <file_path>src/components/Dashboard.tsx</file_path>
  <file_code>// updated code here</file_code>
</file>

The file_operation="UPDATE" attribute tells your parser what action to take without requiring a separate nested tag. JSON can't do this -- you'd need another key-value pair at the same nesting level.

Anatomy of an XML prompt

Effective XML prompts follow a three-part structure: task description, output rules as bullet points, then the XML template. Here is a real prompt for tracking code changes across multiple files:

You are a senior software engineer. Review the following codebase
and implement the requested feature. Output all changed files
in the XML format specified below.

At the end of your response, include the following XML section
with your code changes:

- Always output the full file content, never use placeholders
  or partial code
- Enclose the entire XML block in a markdown code block
- Include ALL changed files in a single <code_changes> block
- Use file paths relative to the project root
- Wrap all code content in CDATA sections

<code_changes>
  <changed_files>
    <file>
      <file_operation>CREATE | UPDATE | DELETE</file_operation>
      <file_path>path/to/file.ext</file_path>
      <file_code><![CDATA[
        // Full file content goes here
      ]]></file_code>
    </file>
  </changed_files>
</code_changes>

Each layer of this prompt does specific work.

Why CDATA matters. Code is full of characters that XML treats as special syntax. An angle bracket < in a JavaScript comparison looks like an opening XML tag to a parser. CDATA sections tell the parser: "Everything between and ]]> is raw content. Don't parse it." Without CDATA, any code containing <, >, or & corrupts your XML output and breaks automated parsing.