A team reports that their security-scanning agent produces results that downstream systems cannot reliably parse. On some runs the agent returns a JSON array of vulnerabilities; on other runs it returns a narrative paragraph; on others it returns a partially structured object with inconsistent field names. Automated ticketing that depends on the agent's output fails unpredictably. What is the most appropriate fix?
Select an answer to reveal the explanation.
Short Explanation and Infographic
If your plumber sometimes sends invoices as PDFs, sometimes as napkin sketches, and sometimes reads the total over the phone, your accounting software is going to have a bad time. Downstream systems need a contract. Defining a strict output schema — and validating against it before anything downstream receives the data — is the right fix.
Full explanation below image
Full Explanation
Defining outputs is a symmetric counterpart to defining inputs, and it is equally important in agent architecture. An agent's output contract — the schema that specifies the structure, field names, data types, and required fields of every response — allows downstream systems to integrate reliably. Without it, outputs vary based on how the model interprets its instructions on a given run, producing the kind of inconsistency described in this scenario.
The correct answer is B. The fix is to define a strict JSON output schema (for example, using JSON Schema or Pydantic models) and enforce it at the agent boundary. The schema should specify: an array field named vulnerabilities, each item containing id, severity (enum: critical/high/medium/low), description (string), affected_file (string), and line_number (integer). The agent must be instructed (via system prompt and function calling with required output structure) to always return this format, and an output validation step should verify schema compliance before results are sent downstream. Non-compliant outputs should be caught and either re-generated or flagged for review.
Why the other options are wrong:
Option A — decreasing temperature — reduces randomness in token selection, which may slightly improve consistency but does not guarantee structured output. Temperature controls creativity, not schema adherence. Even at temperature 0, a model without an enforced output format can still vary its structure.
Option C — replacing with a regex scanner — is an architectural overreaction. AI-based scanners often detect semantic vulnerabilities that regexes cannot. The problem is output consistency, not detection quality. A well-configured AI agent with an enforced schema is both powerful and consistent.
Option D — adapting the downstream system to handle all three formats — treats the symptom rather than the disease. It adds fragile format-detection logic in a place that should not need it, increases maintenance burden, and still fails when a fourth unexpected format appears.
For the exam: 'inconsistent outputs,' 'downstream parsing failures,' 'different formats on each run,' and 'unpredictable structure' all point to a missing or unenforced output schema definition.