One Empty Call, Work Gone
- Admitted
- 2026-10-05
- Source dataset
- BugReAct (When Agents Fail)
- Source
- GitHub, n8n-io/n8n
- Failure mode
- Other
- Agent system
- Tool-calling
- Tool access
- Read-only
- Industry
- Software development
Presenting Behaviour
An AI Agent running within a workflow framework periodically generated tool calls with completely empty input, supplying no parameters at all for tools that declared required fields. When the framework validated one of these calls, schema validation failed on the empty input, and the framework responded by immediately terminating the entire agent execution rather than returning the validation error to the agent as a recoverable observation. All prior work from earlier iterations of the same run was discarded. Testing showed that roughly 12.4% of tool calls produced by the underlying model (33 of 267 calls) contained completely empty input on tools with declared required parameters.
Case Replay
A reconstruction, not a simulation. This sequence is reconstructed from the public incident record and summarised in our own words. It is a static record of what was reported, and nothing here can be run or replayed live.
4 steps
- Empty tool calls. About 12.4% of calls arrive with no parameters.
- Validation fails. The framework checks the empty input. This is where the agent derailed.
- Run terminated. The whole execution ends instead of returning the error.
- Work lost. All earlier iterations are discarded.
Differential Diagnosis
A sporadic model error that should simply be retried, considered and ruled out. A 12.4% rate of empty-input calls is consistent enough to indicate a systematic failure in how the model generates tool calls for this class of tool, not random noise that retries would clear.
The tool declarations are wrong, making the model's empty input correct, considered. If a tool's required parameters are actually optional in practice, the declaration mismatch would explain some failures. But the execution behavior (terminating the run entirely on a schema mismatch rather than surfacing it) would still be wrong regardless of who specified what.
Apraxia, most consistent with the evidence: the model correctly understood that a tool existed and needed to be called, but could not reliably produce correctly formed calls for it, the tool's intended purpose and the model's execution of the call were decoupled.
Working Diagnosis
Apraxia: the model understood which tool to invoke but could not consistently produce correctly-formed calls for it, and the framework's response to malformed calls (terminating the run rather than returning an error) ensured the failure destroyed all preceding work.
Discussion
The destructive part here is not the malformed call itself, a 12.4% tool-input error rate is recoverable if the framework treats it as a recoverable error. The problem is a framework policy that translates 'tool call was malformed' into 'entire run fails and all prior work is lost.' An agent's cumulative progress within a multi-step run should not be at the mercy of a single validation failure; the principled response is to return the error as an observation and let the agent try again.
Mitigation Strategy
Return validation errors as recoverable observations so one bad call does not discard earlier work.
Governance Guardrails
Recoverable validation handling; preservation of run progress.
Typical Presentation in Human Patients
General clinical background, included for context. Not medical advice, and not a diagnosis of any individual.
Apraxia usually follows damage to specific brain regions, often after a stroke. A person with apraxia cannot carry out a previously familiar, purposeful movement (such as waving goodbye or using a comb) on request or by imitation, even though their muscle strength, coordination, and understanding of what's being asked are otherwise intact.
Source Note
GitHub, n8n-io/n8n
https://github.com/n8n-io/n8n/issues/37916