Agent prematurely stops during multi-step tool-call tasks

Prerequisites

• I searched open issues and discussions and did not find an existing report of this bug.
• This is not a security vulnerability. (Vulnerabilities go to GitHub Security Advisories — see SECURITY.md.)
• I am running the latest code from the dev branch (the default branch you get on clone, where fixes land first) and the bug still reproduces there. Please git pull the latest dev before filing.

Odysseus Revision

adaf41520bfa (2026-09-15)

Install Method

Docker (docker compose up)

Operating System

Linux

Steps to Reproduce

1. Start Odysseus in Agent mode.
2. Configure an LLM backend with native tool calling.
3. I reproduced the issue with multiple backends/providers:
   • Ollama
   • LM Studio
   • Gemini API
   • OpenRouter API
   • Mistral API
4. Give the agent a task that requires several sequential tool calls to complete, for example:
   • create calendar entries for multiple days;
   • create/update tasks or notes;
   • perform several web searches/fetches and then compile the results into a document.
5. Let the agent execute the task without sending any additional messages.
6. In many cases the agent stops before completing the whole task, usually after approximately 2-5 tool-call rounds.
7. Send Continue in the same conversation.
8. The agent often resumes from the existing state and continues performing the remaining tool calls.

Expected Behaviour

The agent should continue the tool-calling loop until the requested multi-step task is completed, assuming the required tools are available and their execution succeeds.

The user should not normally need to manually send Continue just to make the agent continue an unfinished task.

Actual Behaviour

The agent sometimes stops before completing a multi-step task.

The stopping point is not deterministic, but in my testing it frequently occurs after approximately 2-5 tool-call rounds.

Sending Continue often allows the agent to continue from the existing conversation and perform additional tool calls.

I also encountered provider/API errors during longer runs. For example, Gemini returned HTTP 400 with:

Please ensure that function call turn comes immediately after a user turn or after a function response turn.

with status:

INVALID_ARGUMENT

This occurred after previous tool calls had already been successfully executed.

Logs / Screenshots

Relevant log excerpts:

The logs show that multiple native tool calls can execute successfully in a single round. For example, one Gemini run produced 5 native tool calls in round 1:

- 4x `manage_calendar`
- 1x `manage_notes`

All 5 were executed successfully, after which another agent round started.

In another run, Gemini completed several tool-call rounds and then returned HTTP 400:

`Google returned HTTP 400`

`Please ensure that function call turn comes immediately after a user turn or after a function response turn.`

The same error occurred again later in the conversation after sending `Continue`.

Relevant log entries show the agent progressing through multiple rounds before the API rejects the conversation state.

I can provide the full log if needed.

Model / Backend (if relevant)

I tested multiple backends/providers and observed the same general behaviour: - Ollama - LM Studio - Gemini API - OpenRouter API - Mistral API The issue therefore does not appear to be isolated to a single provider. The exact model varied depending on the backend. One logged example used: Gemini API / gemini-3.5-flash-lite Another logged example used: Mistral API / ministral-14b-latest

Are you willing to submit a fix?

No — I am only filing the report

Additional Information

I initially suspected this might be specific to my local setup, so I tested several different LLM backends/providers and observed the same general pattern.

The most interesting part is that the agent can successfully execute multiple tool calls, then stop prematurely. Sending Continue usually allows it to resume and continue the task.

The logs also show repeated context compaction/soft-trimming during longer tasks, for example:

Trimming messages: ...

and

soft-trimmed route ...

It may be worth investigating whether context compaction or message reconstruction affects the ordering/continuity of tool-call messages between agent rounds.

The Gemini INVALID_ARGUMENT error strongly suggests that in some cases the message history sent to the provider may contain function/tool-call turns in an order that the provider does not accept.

This issue was observed before the newer tool-approval setting was implemented, so tool approval is not part of this report. Tool execution was already being allowed normally.

I am not sure yet whether this is a general Odysseus bug or an interaction between the agent loop, context handling, and different provider tool-calling formats.

odysseus log.md