Structured Outputs for Claude on Amazon Bedrock: JSON Schema and Strict Tool Use

Amazon Bedrock now offers structured outputs for Anthropic's Claude models, according to a new AWS Machine Learning blog post. You can force a response to match a JSON schema, force tool calls to match a tool's input schema, or do both in one request. AWS says the feature works for all Claude models on Bedrock "where the model is available".

That matters because most production LLM bugs in data pipelines are not reasoning errors. They are a missing field, a trailing comment after the JSON, or a tool argument of the wrong type. Constrained decoding removes that whole class of failure, with a few caveats that AWS spells out and that this post walks through.

Quick reference: what AWS announced

What structured outputs actually are

Structured outputs use constrained decoding. Instead of asking the model nicely to return JSON and parsing whatever comes back, the service compiles your JSON schema into a grammar and restricts which tokens the model may emit at every step. The reply is syntactically valid and matches the schema by construction, subject to the limits below.

AWS describes two complementary mechanisms:

1. JSON output format. Controls the shape of the model's reply. Use it for data extraction, classification, and reporting.
2. Strict tool use. Validates the arguments of tool calls. Use it for agents and function calling.

Both rely on the same constrained decoding machinery, and AWS says you can combine them. If you want the underlying theory of why a schema in a prompt is weaker than a schema in the decoder, our structured output and tool_use guide covers the pattern in depth.

How do I enable JSON schema output on Bedrock?

For InvokeModel with Claude, add output_config.format to the Anthropic-native request body. The type is json_schema and the schema is a real JSON object, not an escaped string. A minimal request body looks like this (the model ID and region are yours to fill in; check the Bedrock structured output documentation for current field names):

{
  "anthropic_version": "bedrock-2023-05-31",
  "max_tokens": 1024,
  "messages": [
    {"role": "user", "content": "Classify this ticket: my invoice total is wrong"}
  ],
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "properties": {
          "category": {"type": "string", "enum": ["billing", "bug", "feature_request", "other"]},
          "urgent": {"type": "boolean"}
        },
        "required": ["category", "urgent"],
        "additionalProperties": false
      }
    }
  }
}

The AWS post includes Python and boto3 examples for data extraction with InvokeModel and for ticket classification with Claude Haiku 5.5, plus a linked sample notebook. Haiku-class models are a natural fit for classification and extraction, where a cheap, fast model plus a hard schema beats a bigger model plus a retry loop. Our Sonnet 5.5 building guide and the Opus 5.5 vs Sonnet 5.5 comparison help with the model choice.

Two related facts from AWS's search-visible documentation: the Converse API uses a different field (outputConfig.textFormat), and the schema is checked against a supported subset of JSON Schema, with unsupported features returning a 400 error immediately rather than silently degrading. Confirm those details against the docs for your endpoint before you rely on them. In particular, the Bedrock user guide currently says the Anthropic Messages API on the bedrock-mantle endpoint rejects output_config.format with a 400 error and points to Converse or InvokeModel on bedrock-runtime instead, so the JSON schema format and strict tool use may not be available on the same endpoint. The user guide also says structured outputs are incompatible with citations (400 error).

How does strict tool use work?

On the bedrock-mantle endpoint, set "strict": true on a tool definition. The AWS example uses the Anthropic SDK's AnthropicBedrockMantle client. With strict mode on, the model's tool call has a valid tool name and inputs that conform to the tool's input schema, so your dispatcher can deserialize arguments without defensive parsing.

This is the part agent builders care about most. A single malformed argument to a payment, deploy, or database tool is an incident. Strict tool use narrows the surface, though it does not make a tool call safe: a perfectly typed call can still be the wrong call. For the safety side, see our write-ups on agent autonomy scoping on AWS and the AgentCore hijack research.

Which schema features are enforced?

Neat schema tags around a page edge, one highlighted, illustrating which JSON schema features Bedrock enforces

This is where the post earns its keep, because the supported subset is narrower than full JSON Schema.

Practical consequences:

• Always set additionalProperties: false on every object. AWS lists it as a requirement.
• Do not trust range checks. If age must be between 0 and 120, the schema will not stop 400. Add a validator (Pydantic, Zod, or plain code) after the call.
• Flatten recursion. A tree of comments or a nested org chart needs a bounded depth or a flat list with parent IDs.
• Keep enums for decisions. Enums are enforced, so use them for categories, statuses, and routing labels. That is the cleanest win.

What can still go wrong?

AWS is explicit that constrained output is not a guarantee in every case. Check stop_reason on every response. Two situations can produce output that does not conform: a refusal, where the model declines and the reply is not your schema, and a max_tokens truncation, where the JSON is cut off mid-object. Treat both as expected branches in your code, not exceptions.

A few more cautions worth building in:

1. Schema-valid is not true. The model can fill a valid field with a wrong value. Extraction accuracy still needs evaluation against labeled examples.
2. Set max_tokens with headroom for the largest object your schema allows.
3. Log refusals separately. A spike in non-conforming responses is a signal, whether from prompts, content, or policy.

Latency and the 24-hour grammar cache

Constrained decoding needs the schema compiled into a grammar first. AWS says "the first request with a new schema might take longer", and compiled grammars are cached per account for 24 hours. Changing the structure of the schema invalidates the cache, but changing only name or description fields does not. Search-visible Bedrock docs add that compilation of a brand-new schema can take up to a few minutes in some cases.

What that means in practice:

• Warm schemas on deploy. Send one cheap request per schema after shipping, so user traffic never pays the compile.
• Do not generate schemas dynamically per request. Every unique structure is a cache miss. Keep a small library of fixed schemas and vary the prompt, not the schema.
• Edit descriptions freely. Tuning field descriptions to steer the model does not blow the cache.
• Expect lower output tokens. AWS notes constrained output can cut output tokens, which may lower inference cost, but the post gives no pricing numbers, so measure it on your own traffic. Our Opus 5.5 task-cost analysis shows how to think about cost per task rather than cost per token.

How is this different from tool use or prompting for JSON?

For many extraction jobs, you can now drop the retry-on-parse-error loop. For agent loops, strict mode removes a category of tool-call errors, but you still need permissioning, sandboxing, and review for risky actions.

Where it sits in the Bedrock model lineup

Bedrock has been adding frontier and open-weight models steadily, and structured outputs is the kind of platform feature that makes switching between them easier, because your contract with the model is a schema rather than a prompt style. Recent examples we covered include Grok 4.7 on Bedrock and GLM-5.3 on Bedrock. Whether structured outputs apply to a given non-Anthropic model is not stated in the Claude post, so check the Bedrock docs for the model you use; the docs reference a separate response_format field for open-weight models.

Anthropic also documents structured outputs for its own API, and says its migration out of beta is done: the older output_format parameter has moved to output_config.format, and beta headers are no longer required. If you maintain code that targets both the Claude API and Bedrock, keep the schema definitions in one shared module and only differ at the request-wrapper layer. See Anthropic's structured outputs documentation for the first-party behavior, since Bedrock model availability can lag it.

A short checklist before you ship

1. Pick one schema per task and keep it static.
2. Set additionalProperties: false on every object.
3. Replace unenforced constraints (ranges, lengths) with post-call validation.
4. Check stop_reason and handle refusals and truncation.
5. Warm each schema after deploy to avoid the compile delay.
6. Evaluate accuracy, not just validity, on a labeled sample.
7. Use strict tool use for any tool that touches money, data, or infrastructure, and add a human or policy check on top.

What this means for what you build or pay

If you run extraction, classification, routing, or agent tool calls on Claude through Bedrock, this is a reliability upgrade you can adopt without changing models: swap the parse-and-retry code for a schema, and cache-warm it. The main cost to plan for is not dollars but the first-request compile delay and the discipline of keeping schemas stable. Pricing is not addressed in the AWS post, so assume standard token billing until your invoice says otherwise.

Details here reflect the AWS post and documentation as of October 20, 2026. Model availability, field names, and limits can change; check the current Bedrock docs before you deploy.

Related reading

• Structured Output with tool_use and JSON Schemas: The Definitive Guide
• Claude Sonnet 5.5 launch and building guide
• Claude Opus 5.5 vs Sonnet 5.5
• Opus 5.5 task cost, cache and effort
• Grok 4.7 on Amazon Bedrock
• GLM-5.3 on Amazon Bedrock
• AWS agent autonomy: know, bound, observe