You are building an agent that generates database migration scripts. Before any scripts are written, you want the agent to output a machine-readable plan that downstream systems can validate and log. Which configuration produces the most useful structured plan output?
Select an answer to reveal the explanation.
Short Explanation
You need a machine-readable plan, not a story. A JSON plan with typed fields can be parsed, logged, diffed, and approved by downstream systems before scripts run. Freeform prose or Markdown won't hold up to automated validation.
Full Explanation
Configuring an agent to output a structured plan means producing a machine-readable artifact — typically JSON or a validated schema — before any destructive or write operations occur. This plan becomes the basis for automated validation, human review, audit logging, and rollback planning.
The configuration that outputs a JSON plan containing an ordered array of migration steps, each with step_id, target_table, operation type, estimated_rows_affected, and rollback_procedure, is correct. This schema can be parsed and validated by a JSON schema validator, logged to an audit trail, displayed in a review UI, and used to generate rollback scripts automatically. step_id supports referencing and ordering, target_table defines scope, operation type identifies actions such as ADD_COLUMN or DROP_INDEX, estimated_rows_affected provides a risk indicator, and rollback_procedure supports recovery planning. Downstream systems can approve or reject individual steps without human reading comprehension.
The freeform paragraph approach produces prose. While readable by humans, it cannot be parsed reliably, cannot be machine-validated against a schema, and cannot be logged in a structured audit system. Two agents might produce semantically identical plans in syntactically incompatible forms, making comparison impossible.
The numbered Markdown list approach improves on prose slightly because it is ordered, but Markdown is not machine-parseable in a reliable way. A numbered list of migration names gives no information about operation type, rollback, or risk, so it is insufficient for validation or approval.
The GitHub issue approach is creative but wrong. A GitHub Issue is a UI artifact designed for human collaboration, not machine ingestion. It adds latency, requires API calls, and cannot be directly consumed by a validation pipeline. The plan should exist as a structured output artifact in the agent's response context, not as a side-effect action.
The exam objective is: 'Configure an agent to output a structured plan.' The canonical pattern is a typed, schema-validated JSON document emitted before any execution tools are called.