- AWS says Claude models on Amazon Bedrock can now be made to return JSON that follows a schema, which it says removes the need for custom parsing and retries.
- The schema controls the shape of an answer. AWS's own guidance says some constraints are not enforced and that refusals and token limits can still break the format.
- Teams should decide which fields feed money, health or legal decisions, and keep content checks on those fields.
Software that talks to software needs a strict handshake. For years, AI models have been the loose part of that handshake. A model asked for data in a set format would usually comply, and sometimes not. Amazon Bedrock now says it has tightened that handshake for Claude. The lesson for leaders is that an enforced format is not the same thing as a correct answer.
What AWS announced
In a post dated October 19, AWS said its Claude models on Bedrock can now be told to reply in a fixed data layout. Developers can reach the feature through either of two Bedrock routes, called bedrock-runtime and bedrock-mantle. The developer supplies a JSON schema, which is a template naming each field and its type. The response is then built to fit it.
AWS says this removes the need for custom parsing, retry logic and post-processing. Its examples span finance, health care and legal work. They include pulling fields from earnings reports, turning clinical notes into patient records, reviewing contracts for terms and obligations, and sorting support tickets.
How the lock works
The method is called constrained decoding. A model writes its answer one small piece of text (a token) at a time. Normally any token is allowed. With constrained decoding, the system refuses tokens that would break the schema while the answer is being written. AWS describes the result as moving formatting from a matter of likelihood to a matter of rule.
Bedrock first checks the schema against a supported subset of JSON Schema Draft 2020-12. For a new schema, it then compiles a grammar artifact, a machine-readable version of the rules. The first request with a new schema can run slower. AWS says compiled grammars are cached for 24 hours, scoped to your account.
Changing the structure of the schema triggers a fresh compilation. Changing only a name or description does not. AWS also says each object must set additionalProperties to false, or the schema is rejected.
Tool calls for agents
AWS lists two mechanisms as available on both endpoints: a JSON output format and a strict mode for tool calls. It demonstrates strict tool use on the bedrock-mantle route, which it describes as built for agentic applications. An AI agent uses tools, such as a weather lookup or a database query, by writing inputs for them. With strict set to true, AWS says the tool input is held to the schema. In its example, a unit field is limited to celsius or fahrenheit.
This matters as more software is built for machine readers. When one AI system hands work to another, the schema is the contract between them. A malformed handoff in a multi-step workflow can stall the whole chain.
A correct form can still hold a wrong answer
Think of a paper form with every box filled in the right format. A clerk can still write the wrong amount in the amount box. Structured outputs police the boxes. They say little about the figures inside.
AWS's own post draws part of this line. It says some schema keywords are accepted by the API but not enforced during generation. Bedrock will take a request containing them without complaint, yet the model may return values that ignore them. The post's list includes numeric limits (minimum, maximum, multipleOf) and string length limits (minLength, maxLength). AWS tells developers to validate these in their own application.
The post also names two situations that can produce responses that do not fit the schema. One is a refusal, when the model declines for safety reasons. The other is a token limit, when max_tokens runs out before the answer is complete. AWS advises checking the stop reason on each response.
Yet AWS also says the response conforms to your schema and that "No additional validation is required." Its closing section describes data pipelines that "need no additional validation." Its own guidance on unenforced keywords, refusals and token limits points the other way. The promise of schema-valid output carries conditions.
The risk is a quiet one. A pipeline with no parsing errors may look healthy while a wrong number flows into a record.
What leaders should ask their teams
First, ask which fields feed decisions about money, health or contracts. Those fields need checks on their values, not just their format. A claimed invoice total should be compared with its line items. A clinical field should be reviewed by a person.
Second, ask who owns the stop-reason handling. A refused or cut-off response should be routed to a person or a retry, not loaded as if it were complete.
Third, ask whether the test data looks like real data. AWS recommends testing schemas with production-representative inputs, because real edge cases often reveal schema design problems.
Fourth, ask about cost and speed. AWS says limiting a response to the schema's fields cuts the number of output tokens, and that this may lower costs for heavy workloads. It gives no figures. Measure it on your own workload, including the slower first request after any schema change.
Structured outputs remove a real source of broken integrations. They do not remove the need to check what the machine says. A tidy format tells you where the answer sits. It does not tell you the answer is right.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS.
