Multi-Part Output Structures

Some tasks require outputs with multiple distinct sections that serve different downstream purposes. The analysis section goes to one system; the JSON summary goes to another; the action items go to a third. Multi-part output structures solve this by placing distinct delimited sections in a single response that can be split by the consuming application.

# Prompt specification for multi-part output

Return your response in three clearly delimited sections.
Use exactly the delimiters shown below — do not modify them.

===ANALYSIS===
[Your free-form analysis here. Markdown permitted. No length limit.]

===JSON_SUMMARY===
{
  "risk_level": "[low|medium|high|critical]",
  "key_issues": ["[issue 1]", "[issue 2]"],
  "recommended_action": "[string]",
  "estimated_hours": [number]
}

===ACTION_ITEMS===
[Numbered list of specific next steps. Plain text. Max 5 items.]

---
Consuming application splits on the delimiter strings.
The ANALYSIS section is displayed to the user.
The JSON_SUMMARY is parsed and stored to the CRM.
The ACTION_ITEMS are extracted and added to the task queue.

1. Choose Delimiters That Cannot Appear in Content Use delimiter strings that will never appear in legitimate output. "===SECTION_NAME===" works well. "---" fails for markdown documents. Angle bracket tags ("<analysis>") work but look like HTML to some parsers. Test your delimiter against the expected content types.
2. Define the Parsing Strategy Before writing the prompt, decide how the consuming application will split sections. Split on the delimiter string, extract content between delimiters, process each section independently. Code this before writing the prompt — the delimiter choice should match the parsing logic.
3. Handle Missing Sections What happens if the model omits a section? Your parser must handle this gracefully. Either validate for all required sections and retry, or define fallback behavior for each missing section. Missing sections should trigger a retry, not a silent failure.