We thought our GPT-5.4 agent got lazier in production — it was a 3-bug workflow teaching it to quit

An n8n agent designed to search, pull documents, compare sources, verify claims, and write grounded answers exhibited a puzzling decline in performance when deployed in production. While it functioned well in staging, once released, the same task often ended after a shallow pass, with shorter outputs, fewer tool calls, more confident wrong answers, and less evidence of multi-step reasoning.

Initial suspicion fell on GPT-5.4, but the real culprit turned out to be a trio of workflow errors – a reduced retry cap, treating partial outputs as success, and an API path rewarding the first acceptable-looking response rather than the best one. These issues caused the agent to stop too early, leading to symptomatic "lazy" behavior.

The production environment imposed additional constraints, such as retry limits, timeout settings, parser requirements, tool wrappers, success conditions, fallback branches, and queue pressure. These factors interacted in ways that "lazy" agents in production often fail to reveal in staging. A strong model within a flawed loop can appear significantly worse than a decent model in a clean workflow.

To avoid misdiagnosing model degradation, it is crucial to run the same task through the exact same scaffold, changing only one variable at a time. In this case, when the workflow was fixed, quality returned to normal. The key takeaway is that production constraints can cause agents to appear less capable than they actually are, emphasizing the need to closely examine the orchestration layer.