AI Agent & LangChainStructured Output Parser✓ Checked 15 September 2026 · n8n 2.39.5 (source read on master @ 2.40.0)

Model output doesn't fit required format

Your Structured Output Parser got text back from the model that either isn't valid JSON or doesn't match the schema you gave it — and if you built that schema with Generate from JSON Example, every field in your example is mandatory, so one missing key is enough to throw this.

Upgrading n8n will not fix it. This is thrown by design, and it's been reported across 1.88, 1.101, 1.107 and 1.112 on Claude, Gemini, GPT-4o and GPT-3.5 alike. The GitHub issue for it is closed as not planned.

First: find out which of three failures you have

The Structured Output Parser does three things in order, and the error message is identical whichever step fails. That's why the fixes people post in the forum contradict each other — they're fixing different bugs.

Strip a markdown code fence, if there is one
JSON.parse() whatever's left
Validate the result against your schema (n8n uses Zod)

So before changing anything, read what the model actually sent. Two ways:

Open the failed execution and click the Structured Output Parser sub-node. Its input is the raw model text.
Or disconnect the parser from the Agent or Chain and re-run on the same input. The node now returns the model's reply untouched.

If it isn't JSON, you have Failure A. If it's JSON but a key is missing, spelled differently, or the wrong type, you have Failure B.

Failure A — it isn't JSON

n8n's fence stripping is stricter than people expect. It walks the reply line by line and only strips a fence when the opening line is exactly three backticks, or three backticks followed by json, with nothing else on that line — and the closing line is three backticks alone.

These all survive stripping and then blow up JSON.parse:

an opening fence with the language in caps
an opening fence with a space before json
a fence tagged javascript or js instead of json
the fence and the first { on the same line
no fence at all, just Here is the JSON you asked for: {"…"}

Prose before the opening fence is fine, and so is prose after the closing fence. It's the fence line itself that has to be clean.

The fix is in the prompt, not the parser. Put this in the system message, as the last line so it isn't buried:

Respond with a single JSON object and nothing else. No markdown, no code fences, no explanation before or after.

If your model node has a response-format option that forces JSON, turn it on as well — that removes the failure at the source instead of asking the model nicely.

Failure B — it's valid JSON, but the wrong shape

This is the common one, and it usually traces back to a single documented behaviour:

Generate from JSON Example treats every field in your example as required.

So if your example is

{ "company": "Acme", "amount": 1200, "note": "paid late" }

then the model must return note on every single item. On the run where there's nothing to note, it omits the key, Zod rejects the object, and you get this error — on item 40 of 50, which is why it looks intermittent.

Fix: switch Schema Type to Define using JSON Schema and write the schema by hand, putting only the genuinely mandatory keys in required:

{
  "type": "object",
  "properties": {
    "company": { "type": "string" },
    "amount":  { "type": "number" },
    "note":    { "type": "string" }
  },
  "required": ["company", "amount"]
}

Three more things that cause shape failures, in the order they're worth checking:

$ref is not supported. n8n documents this. A schema that factors out a repeated sub-object with $ref will not work — inline it.
Free-text fields where a fixed set would do. If a field has four legal values, say so with enum. A model asked for "intent": "string" will eventually invent a fifth category; a model asked for "intent" from an enum of four will not.
Depth. Nested objects and arrays-of-objects fail far more often than a flat object. If you can flatten it, flatten it.

Failure C — check you're not reading the wrong error

If the message you actually got was "The AI model returned an empty response to the Structured Output Parser", that's a different error with a different cause: the model ran out of output tokens before it finished the object. Raise the model's max output tokens, shorten the prompt, or simplify the schema. Nothing above applies.

Why an Agent fails where a Chain succeeds

Several people in the main forum thread report the same prompt and the same schema working once they swap the AI Agent for a Basic LLM Chain. That isn't superstition. Under an Agent, the parser validates the agent's final answer, and an agent that has just run two tool calls has a strong habit of narrating what it did before answering. A chain has no tools and nothing to narrate.

If you don't need tool calling, use the chain. It's a smaller surface.

About the Auto-fixing Output Parser

The Auto-fixing Output Parser wraps another output parser, and when the first one fails it calls out to another LLM to repair the output. It's worth adding — but be clear about what it can and can't do:

It fixes Failure A well. Malformed JSON, stray fences, a trailing comma: a second model reliably cleans these up.
It does not fix Failure B. If your schema requires a field the model has no data for, the repair model can't invent it either. You now get the same error after two model calls instead of one, at twice the cost and twice the latency.

So: fix the schema first, then add auto-fixing as a seatbelt. Not the other way round.

Why this happens at all

An LLM produces tokens, not objects. The Structured Output Parser is a validator bolted onto the end of a process that has no native concept of a schema, so the schema is enforced after the fact by throwing. Every design decision follows from that — which is why the durable fix is always to shrink the gap between what you ask for and what the model can reliably produce, rather than to catch failures harder.

Concretely, the workflows that don't hit this error are the ones that ask for a flat object, with a short list of required keys, with fixed-value fields declared as enums, and a system message that forbids anything but JSON.

Related errors

The AI model returned an empty response to the Structured Output Parser — token exhaustion, not schema mismatch.
Received tool input did not match expected schema — same class of problem, one layer up: the model's tool call arguments failed validation rather than its final answer.
No tool output found for function call — the agent called a tool and got nothing back.
A Chat Model sub-node must be connected — the agent has no model attached at all. Documented by n8n.

A worked example

A triage workflow I built applies both of the rules above to inbound email. The intent field is an enum of six fixed values rather than a free-text string, so the model cannot invent a seventh category on the one message that doesn't fit. And every company name and figure it extracts has to appear literally in the source message before anything downstream accepts it.

The enum removes the invented-value failure. The literal check removes the confidently-wrong one. Neither costs an extra model call, which is why they beat adding a repair pass on top.

Sources: n8n's source for the Structured Output Parser; the n8n docs for the Structured Output Parser and Auto-fixing Output Parser; n8n-io/n8n issue #18765; community.n8n.io thread 106424. n8n's own documentation does not currently cover this error.

Last verified 15 September 2026 against n8n 2.39.5 (source read on master @ 2.40.0). n8n changes these messages between releases; if the wording you see differs, the version above is what this page was checked against.