7. Layer 2: Structured Output

Problem Solved

The model produces text, but the harness needs reliable decisions. Layer 2 defines the contract between what the model emits and what the system does. The model must produce output that follows the contract, whether by prompting alone or by guided generation at decode time (13).

Service Provided to the Layer Above

Layer 2 converts raw model output into typed intents:

Intent	Meaning
Final answer	The agent believes the task is complete
Tool request	The agent wants the harness to execute a tool
Clarification	The agent needs more information from the user
Plan update	The agent revises its multi-step strategy
Abort	The agent cannot or should not continue

The exact protocol may use JSON, XML, function-calling APIs, or another format. The architectural requirement is the same: the harness must be able to parse and validate the model’s intended action.

Model Proposes, Harness Disposes

This is a core principle.

+-------------+        +--------------+        +-------------+
| LLM Engine  | -----> | Output Parser| -----> | Validator   |
+-------------+        +--------------+        +-------------+
                                                |
                                   valid intent | | invalid intent
                                                 v v
                                           +-----------+
                                           | Harness   |
                                           | decision  |
                                           +-----------+

The model may propose an action. The harness decides whether that action is structurally valid, permitted, and safe to execute.

Tool-Call Contract

A tool request should specify:

Field	Purpose
Tool name	Which declared tool is being requested
Arguments	Values bound to the tool’s parameters
Intent class	Read, compute, mutate, submit, abort
Optional rationale	Helps debugging and auditing, not execution

A common concrete shape: the contract is defined once in code, a class or function with typed arguments and a description. For the model, the harness serializes it to text, the tool name, the description, and a list of argument names and types. For the harness, the same contract maps to the code primitives it executes. The model sees the serialized form. The harness runs the code form.

The model can only pick a tool it understands. A tool name alone is rarely enough. The harness must provide a clear, detailed description of what the tool does, what it needs, and what will happen after it runs, both the wanted effects and the unwanted ones (14)(15). Poor descriptions lead to the wrong tool being picked, even when the right tool is available.

The contract must be checked before execution:

• Tool name exists in the declared tool set.
• Required arguments are present.
• Argument types and values are valid.
• Argument values satisfy policy constraints.
• The caller is allowed to use that tool.
• The action is within step, cost, and permission budgets.

Design Rules

1. Keep the output protocol simple.
2. Require an explicit final-answer intent.
3. Reject unknown tools instead of guessing.
4. Validate arguments before any side effect.
5. Treat invalid output as a controlled error, not as executable text.
6. Limit retry cycles for malformed output.
7. Log the raw model output and the parsed intent separately.

Failure Modes

Failure	Example	Architectural fix
Malformed structure	Invalid JSON or incomplete block	Parser with controlled retry
Unknown tool	Model invents a tool name	Tool allowlist
Missing argument	Tool called without required field	Schema validation
Invalid argument	Path, ID, amount, or range out of bounds	Argument policy checks
Ambiguous intent	Text contains both answer and tool request	Explicit intent priority rules
Silent refusal	Model says it cannot act but provides no structured abort	Required abort/clarification intent