I have an agent workflow using the n8n MCP integration. A week ago, ChatGPT could autonomously execute a chain of tools in a single response:
Execute workflow
Capture executionId
Call get_execution(includeData=true)
Inspect results
Execute the next workflow
Repeat until completion
Return only the final result
My workflow depends on sequential execution where each step consumes the previous step’s output.
Currently, ChatGPT stops after the first or second tool invocation and returns control to the user, preventing autonomous orchestration, even though all required tools (execute_workflow, get_execution, etc.) are available.
The exact same workflow and prompt continue to work in another LLM environment, suggesting a regression or runtime limitation rather than a prompt issue.
It would be valuable to restore support for multi-step autonomous tool execution for agentic workflows.
The detail I’d isolate is whether the stop happens after a large/verbose tool result, or after a fixed number of calls. If it correlates with result size, it may be context pressure or a runtime cap on continued tool execution rather than the model deciding to stop.
A small repro would help: make execute_workflow return only {executionId,status,nextToolHint}, and make get_execution return a tiny synthetic result. If the chain continues with tiny payloads but stops with includeData=true, the mitigation is to split “inspect results” into a summary endpoint or cursor page instead of asking the model to carry the whole execution body.
Also log whether the second step was “tool not called” vs “assistant returned asking user to continue.” Those are different failures: one is tool availability/registration, the other is an autonomy budget or stop-policy boundary.
Thanks for the suggestions. I ran a smaller experiment to isolate the issue.
The failure actually occurs before “get_execution(includeData=true)” is ever called.
I asked ChatGPT to perform only two sequential tool calls in a single response:
1. “execute_workflow”
2. “get_execution”
The first call succeeds and returns an “executionId”, but the assistant immediately ends its response instead of issuing the second tool call. So the chain breaks before any large payload is returned.
That suggests the issue isn’t caused by “includeData=true” or the size of the execution result, because we never reach that point.
What’s puzzling is that this worked perfectly a few weeks ago. The exact same workflow could autonomously execute a workflow, inspect the execution, launch the next workflow, and continue until completion without any user intervention.
I can also reproduce the expected behavior today using Claude with the same project instructions, the same n8n instance, and the same workflows. The only variable that has changed is the model/runtime.
So at this point I’m trying to determine whether this is:
- a regression,
- a runtime policy change around autonomous tool chaining,
- or a limitation specific to the current ChatGPT tool execution environment.
If anyone from OpenAI has insight into whether autonomous multi-tool execution behavior has changed recently, I’d be very interested.