Dynamic Format for Agent Tool Response Prompt Template

This prompt is for AI agent builders whose tools must return results consumable by different downstream systems or audiences. The core job-to-be-done is producing a single tool response that adapts its format based on a response_target parameter: structured JSON for tool chaining and API consumption, Markdown for human-in-the-loop review dashboards, or raw text for logging and audit trails. The ideal user is a platform engineer or agent developer wiring tool outputs into a multi-agent architecture where the consumer of a tool's result is not known at design time. You need this prompt when a single tool serves multiple callers with incompatible format expectations, and you want the model to enforce the format contract rather than relying on post-hoc transformation layers that can drop fields or misinterpret structure.

Do not use this prompt when the output format is fixed and known at build time. If every consumer expects the same JSON schema, use a schema-first prompt with strict field definitions instead. Do not use it when the tool response is always consumed by a human—skip the format switch and optimize for readability. Avoid this pattern when the format decision depends on complex business logic better handled in application code; the prompt works best when the format selector is a simple enum passed as a parameter. For high-stakes financial, healthcare, or compliance workflows, always add a human review step before the formatted output is consumed by downstream systems, regardless of the selected format.

Before implementing, confirm you have a clear response_target taxonomy with exactly the values your system supports—typically json, markdown, and text. Map each target to a concrete output contract: JSON requires a specific schema with typed fields, Markdown requires section headings and readable structure, and text requires a flat string suitable for log ingestion. Wire the prompt into your agent harness so the response_target value is injected from the calling agent's context or configuration, never from untrusted user input. After deployment, evaluate format compliance per target: JSON must parse without errors and match the declared schema, Markdown must render correctly in your review UI, and text must contain no unescaped control characters that could break log pipelines.

This prompt template is the core instruction set for an agent tool that must return results in a format consumable by different downstream systems. It accepts a [RESPONSE_TARGET] parameter that dictates whether the output should be structured JSON for tool chaining, Markdown for human-in-the-loop review, or raw text for logging. The template enforces strict format contracts per target, ensuring that a JSON response is always a valid, parseable object and a Markdown response always includes clear section headers. Copy the block below and replace the square-bracket placeholders with your specific tool's input data, context, and constraints.

textCopy
You are a tool response formatter for an AI agent system. Your job is to return the result of a tool execution in the exact format specified by the [RESPONSE_TARGET] parameter. Do not add commentary, explanations, or apologies outside the specified format.

## INPUT DATA
Tool Name: [TOOL_NAME]
Tool Result: [TOOL_RESULT]
Execution Status: [STATUS]
Error Details (if any): [ERROR_DETAILS]

## RESPONSE TARGET
[RESPONSE_TARGET]

## FORMAT RULES
You must follow the format rules for the selected [RESPONSE_TARGET] exactly.

### If [RESPONSE_TARGET] is "json"
Return a single valid JSON object with no markdown fences, no trailing commas, and no comments. The object must conform to this schema:
{
  "tool_name": "string",
  "status": "success" | "error" | "partial",
  "data": <the complete tool result, preserving its original structure>,
  "error": null | {"code": "string", "message": "string"},
  "metadata": {
    "format": "json",
    "generated_at": "ISO-8601 timestamp"
  }
}

### If [RESPONSE_TARGET] is "markdown"
Return a Markdown-formatted response suitable for human review. Use the following structure:
# Tool Result: [TOOL_NAME]
**Status:** [STATUS]
**Generated:** [current ISO-8601 timestamp]

## Result
[TOOL_RESULT formatted as readable markdown with appropriate headers, lists, and emphasis]

## Errors
[ERROR_DETAILS if status is error or partial, otherwise "None"]

### If [RESPONSE_TARGET] is "text"
Return a plain text log entry with no markdown formatting. Use this exact structure:
[ISO-8601 timestamp] [TOOL_NAME] [STATUS]
Result: [TOOL_RESULT as compact text]
Error: [ERROR_DETAILS or "None"]

## CONSTRAINTS
- Do not wrap the output in markdown code fences unless the target format itself requires them.
- If [RESPONSE_TARGET] is not one of "json", "markdown", or "text", default to "json" and set status to "error" with an appropriate error message.
- Never invent or modify the tool result data; preserve it exactly.
- If the tool result contains sensitive-looking data, do not redact it; the caller is responsible for data hygiene.

To adapt this template, replace the placeholders with your actual tool context. The [TOOL_RESULT] placeholder should receive the raw output from your tool execution step. If your agent framework passes structured objects, serialize them to a string representation before insertion. The [RESPONSE_TARGET] parameter should be set by the calling agent or orchestrator based on the downstream consumer: use "json" when the next step is another tool or API, "markdown" when a human needs to review the output in a dashboard or chat interface, and "text" when writing to a log aggregation system. For production use, add a post-processing validation step that parses the model output and confirms it matches the requested format before forwarding it to the consumer.

This prompt is designed to sit inside an agent's tool-response handler—the code that runs after a tool executes and before the result is passed to the next agent, a human reviewer, or a logging sink. The harness must inject three runtime values into the prompt's placeholders: [TOOL_OUTPUT] (the raw result from the tool call), [RESPONSE_TARGET] (one of agent, human, or log), and [TOOL_NAME] for traceability. The model's job is to reformat the raw output into the contract specified by the target, not to modify the underlying data. Treat the model as a deterministic serializer, not a reasoning step. If the tool output already matches the target format, the model should pass it through with minimal changes—add a guard in your harness to skip the LLM call entirely when a simple format check passes, saving latency and cost.

Wire the prompt into a tool execution wrapper function. After the tool returns, call the LLM with this prompt and parse the response. The critical implementation detail is format-specific post-validation. For agent target, validate the output against your tool-chaining JSON schema—reject responses missing required fields like status, data, or error. For human target, check that the output contains no raw JSON blobs and that Markdown tables render correctly in your UI. For log target, confirm the output is a single flat string with no markdown formatting. Implement a retry loop: if validation fails, re-invoke the prompt with the validation error appended to [CONSTRAINTS]. Cap retries at 2 to avoid infinite loops on fundamentally malformed tool outputs. Log every format switch and validation failure with the [TOOL_NAME] and [RESPONSE_TARGET] for debugging.

Model choice matters here more than for most prompts. This task requires strict instruction following, not creative generation. Prefer models with strong JSON mode and format-following benchmarks. Avoid models known to inject conversational filler into structured outputs. Set temperature=0 and disable sampling parameters. If your agent framework supports it, use structured output APIs (e.g., OpenAI's response_format with a JSON Schema for the agent target) rather than relying solely on prompt instructions. For the human and log targets, plain text completion is sufficient. The biggest production risk is format bleed: the model produces a hybrid output that mixes JSON fields with Markdown explanations. Catch this in validation by checking that the response is parseable as exactly one format. If your tool outputs contain PII or sensitive data, add a redaction step before the LLM call—this prompt should never be the place where data minimization happens.