Since I installed the latest version “2.25.6”, whenever I use a “Basic LLM Chain” node with a structured output parser, I get an error “Failed to parse agent steps”.
Basically, it’s not going through the structured output parser node.
I tested it with the “AI Agent” node and it works fine.
Based on what you’re saying, it seems like a specific issue with how the Basic LLM Chain node handles agent steps when used together with Structured Output Parser in version 2.25.6. In many cases the workflow doesn’t even reach the Structured Output Parser node and returns Failed to parse agent steps, whereas the same use case works correctly if you switch to the AI Agent node.
For now, using AI Agent is a good temporary solution, but it would be good if the team could confirm whether this is a known bug in Basic LLM Chain in 2.25.6 or if there’s any recommended configuration to avoid this error.
I ran into something similar after upgrading and it’s worth checking a few things before assuming it’s a full bug.
First, delete the connection between the structured output parser and the Basic LLM Chain node completely, then reconnect it fresh. After version upgrades the sub-node connections sometimes break silently and rewiring them fixes it without changing anything else.
Second, double check your structured output parser schema. Sometimes a small schema mismatch that previous versions were forgiving about becomes a hard failure in newer versions.
If neither of those work, the quickest workaround right now is switching to the AI Agent node since you’ve confirmed it handles structured output fine on this version. For most use cases it does the same job.
Also check the n8n GitHub and search for Basic LLM Chain structured output 2.25.6 — if others hit the same thing after upgrading there may already be an open issue or a fix coming in a patch.
The error message itself is interesting because “Failed to parse agent steps” normally belongs to agent flows, not a Basic LLM Chain. That tells me something in 2.25.6 changed how that node processes the parser output internally. Worth raising a GitHub issue if nothing comes up in your search.
Hit this same error a few weeks ago — Basic LLM Chain with a Structured Output Parser, “Failed to parse agent steps,” same as described here. Can confirm it’s version-specific: updating n8n fixed it for me. I don’t have the exact version I was on when I hit it, but I’m on 2.34.6 now and the Structured Output Parser is getting called correctly instead of getting skipped.
Didn’t dig into what changed internally, but the pattern lines up with what @akingbade-Samuel said above — something in how that version handled the parser output changed, and it reads as a bug that got patched rather than a config issue on the user side. Reconnecting the nodes or touching the schema didn’t do anything for me; the version update was what fixed it.
Writing up the full case (setup, error, fix, what I tried before landing on the update) as its own post since it might help if someone finds this by searching the exact error text. Will link it here once it’s up.
@TeSIdrah’s version hunch is right, and there’s a specific number to put on it. This was a confirmed bug, issue #29903, fixed by PR #33338. That merged on 1 July and shipped in 2.30.0 on 7 July, with a backport to the 2.29.4 beta. So anything from 2.30.0 up is clear, which lines up with 2.34.6 working.
The root cause explains the odd parts of this thread. @langchain/core was being loaded as both ESM and CommonJS, so Node ended up holding two separate copies of the module and instanceof BaseMessage stopped returning true. The Basic LLM Chain output then fell through to getAgentStepsParser(), which is written for agent flows and expects AgentFinish or AgentAction[], which is why a node that isn’t an agent throws an agent error. It also explains why the AI Agent node was unaffected, and why reconnecting the sub-node or adjusting the schema changed nothing. The fix replaces the instanceof check with BaseMessage.isInstance(), which matches on a symbol instead.
@Pedro_de_Pedro if you are still on 2.25.6, upgrading past 2.30.0 is the entire fix, no workflow changes needed. @TeSIdrah your write-up would still be useful for anyone searching the error text, and linking #29903 in it would give them the version number too.
@Lopez Thanks for the detail — that closes the gap I couldn’t fill. Good to have the actual root cause instead of just “the update fixed it.” I’ll link #29903 in the Tutorial write-up so anyone landing here from a search gets the version number and the why, not just the fix.
Glad I could help! Linking the issue in the Tutorial write-up is a great idea that way, anyone facing the same problem can quickly understand both the fix and the root cause. Thanks for adding that context.