Agent & Protocol · Toolkit

Tool-Use & Structured Output

SIMULATEDVerified Jul 2, 2026

Getting JSON out of a model is easy. Getting valid JSON, every time, into a system of record is reliability engineering — schema, validation, and a corrective retry.

Same instrument · three industries — pick a use-case to reconfigure the run

Raw input

Target schema

  • intentenum(open_dispute|status|general)*
  • account_idstring|null*
  • amount_usdnumber|null*
  • sentimentenum(positive|neutral|negative)*
  • priorityenum(low|med|high)*
  • summarystring*

* required key must be present (nullable where typed).

Press Extract to run the sample through the schema gate.

Where the gate sits

Model

raw JSON

Validate

schema + retry

System of record

only valid passes

The retry is the reliability

The first pass is often almost-right — a string where a number belongs, a missing key. A validation gate with a single corrective retry turns "usually valid" into "always valid or explicitly flagged." That's the difference between a demo and production.

Steering-committee takeaway: Where outputs feed systems of record, the validation gate is not optional. I place it between the model and the write.

How this is built

Each sample targets a JSON schema (typed, nullable, required keys). The output is validated key-by-key; on failure the errors are fed back in a corrective retry and re-validated.

Extractions are authored and deterministic (not live model output); the hard sample's first attempt is constructed to fail schema validation so the corrective retry is visible. A live-model variant is designed for but not wired today, so the badge stays SIMULATED.

Stack: Next.js (static) + shared design system; client-side.

Limitations: the extractions are authored illustrations, not live model output; custom text needs a live model (roadmap). Real deployments add a max-retry cap and a dead-letter path for repeated failures.