Summary

Solid fix for #944 — restores parallel tool_calls support that GAIA's own default model (Gemma-4-E4B) needs. The PR correctly drains all N calls before transitioning to error recovery, preserves model-supplied tool_call_ids for spec-strict OpenAI providers, surfaces assistant content emitted alongside tool calls, and now emits a well-shaped assistant turn (content + tool_calls[]) on the next LLM round. Test coverage is thorough — 9 new tests across parser and integration layers, all 4 acceptance criteria from the issue are pinned. Most important thing for the author: a few minor cleanups and one nontrivial duplication that's worth a follow-up but not blocking.

Issues Found

🟢 Minor

1. Dead pre-loop assignment of last_error (src/gaia/agents/base/agent.py:2869)

The last_error = None reset inside the fan-out is only ever read inside the same loop body, where it's already unconditionally re-assigned in the if is_error: branch before being consumed by console.print_error(last_error). There is no post-loop reader (the legacy last_error outer scope is repurposed elsewhere). It's dead initialization.

                tc_list = parsed["tool_calls"]
                any_error = False
                fanout_repeat_break = False

2. _QUERY_TOOLS tuple duplicated between fan-out and legacy paths (agent.py:2918 vs agent.py:3112)

Same 3-tuple defined twice in the same function. Promote to a class-level constant (e.g. _QUERY_DEDUP_TOOLS) so a future addition (e.g. query_chunks) only has to be added in one place. Not blocking — feel free to defer.

3. Significant logic duplication between fan-out and legacy single-call paths (agent.py:2866-3027 vs agent.py:3032-3204)

The fan-out body mirrors ~80 lines of the legacy single-call path almost verbatim: loop detection, query-tool dedup, _post_process_tool_result, _handle_large_tool_result, previous_outputs.append, error classification, error-message extraction. Two near-identical implementations are a drift hazard — the next bugfix in one block will silently miss the other (the legacy block already has subtly different logic for plan/step counter and STATE_COMPLETION that the fan-out skips, which is intentional but undocumented in the diff).

Not blocking for this PR — the duplication is reviewable and the comment at line 2849 calls out the asymmetry. But worth a follow-up issue to extract _dispatch_single_call(tool_name, tool_args, tool_call_id, ...) and have both sites call it. Reference pattern: similar deduplication helpers exist in src/gaia/agents/base/agent.py (e.g. _create_tool_message, _handle_large_tool_result).

4. Test assertion in test_three_calls_one_errors_all_drain is over-permissive (tests/unit/agents/test_parallel_tool_calls.py:768-770)

assert agent.execution_state == agent.STATE_ERROR_RECOVERY or any(
    "Recovered" in str(s) for s in (agent.last_result or {}).values()
)

The or short-circuits — if either branch is true, the test passes. The first branch is the actual acceptance criterion (transition to STATE_ERROR_RECOVERY happens after draining all N calls); the second branch describes the post-recovery state after the second LLM round. Either passes, so the test will pass even if N drain stops early but recovery happens later. Tighten by asserting both: that error recovery WAS entered (e.g. by inspecting agent.error_history for the right error_count increment, or by stubbing the second LLM response to not produce a final answer and asserting STATE_ERROR_RECOVERY directly), and separately that the final result mentions recovery. As written, the test still passes pre-fix if the first errored call raised and the second LLM round happened to emit "Recovered" — unlikely but uncovered.

5. Streaming path is exercised only implicitly (tests/unit/agents/test_parallel_tool_calls.py:540)

The fixture sets a.streaming = False. The streaming branch at agent.py:2273-2293 produces the same sentinel envelope on is_complete chunks, so it should flow through _parse_llm_response identically — but no test pins that. Consider one streaming smoke test (set streaming=True, stub send_messages_stream to yield a single is_complete=True chunk carrying the parallel envelope) so a future change to the streaming-completion path doesn't silently regress parallel calls.

Strengths

• Acceptance criteria genuinely pinned in tests, not just code. The five test classes map 1:1 to the issue criteria (a/b/c + no-misleading-prompt + single-call regression). The _native_envelope helper makes the fixtures readable. _stub_chat's "called more times than preloaded" assertion is a nice trap for runaway loops.
• Backward-compat strategy is clean. Populating legacy tool/tool_args only when len(normalised) == 1 and intentionally omitting them for N>1 forces the new code path everywhere it matters, with zero churn for embedded-JSON consumers. The docstring at agent.py:944-958 documents the contract precisely. The test_parse_native_parallel_calls_returns_list assertion that "tool" not in result for N>1 is exactly the right pin to prevent regressions where someone re-introduces the legacy field.
• Tool result correlation now actually works. Fixing _create_tool_message to accept tool_call_id and propagating the model's real id closes a long-standing latent bug — the synthesised uuid was never linked back to anything, and any spec-strict downstream consumer would have rejected the assistant message shape. The single-native-call regression test (test_single_native_call_uses_real_tool_call_id) explicitly pins this.
• reasoning_content fallback in the provider (lemonade.py:311-315) is a genuinely useful catch — some llama.cpp builds put the model's pre-call thought there instead of content, and the comment explains why exact-None discrimination matters per OpenAI spec.

Verdict

Approve with suggestions. The minor items above are non-blocking; the duplication in #3 deserves a follow-up issue but doesn't justify holding this fix, since #944 is an active capability regression on the default model. Suggest applying #1 inline before merge and tracking #3 separately.

Summary

Closes #944. The agent loop rejected any LLM response with more than one entry in the OpenAI tool_calls array — a NotImplementedError raise that then routed into the generic "malformed arguments" recovery prompt and bailed after three retries with zero tools fired. Tool-calling-trained models, including GAIA's own default Gemma-4-E4B-it-GGUF (#865), routinely emit parallel tool_calls on multi-intent inputs. Result: a silent capability regression — the default model could not handle multi-intent utterances.

This PR makes the loop drain all N calls sequentially in the same iteration before re-prompting, matching OpenAI Chat Completions tools-API semantics.

What changed

• Parser (Agent._parse_llm_response) — normalises native tool_calls into a list of {id, name, tool_args} entries. Single-call legacy fields stay populated for N==1 so embedded-JSON consumers are unaffected; for N>1 callers must use the new tool_calls field.
• Loop (Agent.process_query) — new fan-out branch dispatches each call sequentially with proper console / dedup / post-processing per call. Errors don't short-circuit the drain: all N results land in conversation history before transitioning to STATE_ERROR_RECOVERY. The legacy single-tool branch is gated to embedded-JSON only so native single calls go through the new path too.
• Assistant message bookkeeping — emits a proper OpenAI-shape assistant turn (content + tool_calls[]) instead of stuffing the raw {"__tool_calls__": ...} sentinel envelope into content. Tool result messages now reference each call's real tool_call_id (was synthesising fresh uuids that didn't link back to anything — broke disambiguation for parallel-same-name calls).
• Provider (LemonadeProvider) — surfaces assistant text emitted alongside tool_calls (some Gemma variants explain themselves before calling) in the envelope's content instead of dropping it.
• Misleading recovery prompt — the "malformed arguments" copy is no longer triggered for parallel calls because parsing now succeeds. The copy itself is unchanged for the legitimate ValueError arg-parsing case it was written for.

Test plan

• pytest tests/unit/agents/test_parallel_tool_calls.py -xvs — 5 new integration tests covering issue Agent loop rejects parallel tool_calls from native tool-calling models (Gemma-4-E4B default) #944 acceptance criteria (a/b/c + no-misleading-prompt + single-call regression).
• pytest tests/unit/test_tool_call_priority.py -xvs — 4 new parser-layer tests (parallel-returns-list / three-calls-mixed-args / content-alongside-tool_calls / synthesised-id-when-missing) and 1 updated single-call test asserting the new shape.
• pytest tests/unit/ --timeout=60 — 1800 passed, 14 skipped, 0 failed.
• python util/lint.py --all — passes (1 Black auto-fix applied).
• Reproducer from the issue (Gemma-4-E4B + 4-event utterance against running Lemonade) — author has the harness; happy to run if a real-hardware sanity check is wanted.

Should I close my pull request at #945 because I don't want to add any confusion to this

Summary

Solid, well-motivated fix for a real default-model regression: Gemma-4-E4B (the GAIA default per #865) was emitting parallel tool_calls and the agent was hard-rejecting them, retrying with a misleading "malformed arguments" prompt and bailing with zero tools fired. The implementation is faithful to the OpenAI Chat Completions tools API contract — N calls drain in one loop iteration with proper tool_call_id correlation, errors don't short-circuit, and assistant text emitted alongside tool_calls is preserved. Strong test coverage (5 new integration tests + 4 new parser tests) matches the issue's acceptance criteria.

The single most important thing the author should know: the new fan-out path duplicates ~100 lines of tool-execution logic from the legacy single-tool path (repeat detection, query dedup, _post_process_tool_result, _handle_large_tool_result, error classification). It works today, but creates real drift risk. See the first item below.

Issues Found

🟡 Important — Tool-execution logic duplicated between fan-out and legacy single-tool path (src/gaia/agents/base/agent.py:2884-3045 vs. :3050-3222)

The new fan-out at L2884 and the legacy embedded-JSON branch at L3050 share essentially identical bodies: print_tool_usage → start_progress → repeat detection (L2908-2920 mirrors L3091-3107) → _execute_tool → query-dedup block (L2935-2963 mirrors L3128-3153) → _post_process_tool_result → _handle_large_tool_result → previous_outputs append → error classification (L2999-3028 mirrors L3190-3222). The only meaningful behavioural deltas are:

1. The fan-out passes tool_call_id=tc["id"] to _create_tool_message; the legacy path doesn't.
2. The fan-out drains all N before transitioning to STATE_ERROR_RECOVERY; the legacy path transitions on the first error (correct for N=1).
3. The fan-out skips the "plan + tool both present → defer to plan" guard at L3062-3068 and the single-step STATE_COMPLETION flip at L3071-3075.

Item (3) is the one worth a second look — see the next two bullets. But the broader concern is maintenance: the next contributor who fixes a bug in error classification or query dedup has to remember to fix it in two places. A follow-up that factors _dispatch_single_call(tc_name, tc_args, tc_id) and has both paths call it would erase the drift risk. Not a blocker for this PR (refactoring the legacy path into the fan-out shape carries regression risk for embedded-JSON consumers), but worth filing.

🟡 Important — Plan-vs-tool_calls priority guard missing in fan-out (src/gaia/agents/base/agent.py:2884)

The legacy path at L3062-3068 has:

if "plan" in parsed and self.current_plan and self.total_plan_steps > 0:
    logger.debug("Plan and tool both present - deferring to plan execution logic")
    continue  # Skip tool execution, let plan execution handle it

The fan-out has no equivalent. If the planner emits native tool_calls and a plan field in the same response (rare but the be24697 commit message acknowledges this is possible), the fan-out fires the tool_calls immediately rather than deferring to plan execution. Could be intentional (parallel calls don't fit the single-step plan model), but the asymmetry is undocumented. Either add the same guard for symmetry, or add a comment explaining why parallel calls bypass plan deferral.

🟢 Minor — last_error = None reset wipes function-level state on every fan-out entry (src/gaia/agents/base/agent.py:2887)

last_error is declared at function scope on L1934 and consumed in the error-recovery prompt at L2237. The legacy path at L3197 only assigns inside if is_error:, so last_error is preserved across iterations. The fan-out unconditionally resets to None at L2887 on every entry, which means a prior iteration's error context is wiped even if this iteration's fan-out has no failures. Probably benign in practice (state transitions to STATE_ERROR_RECOVERY on the same iteration that records the error, and last_error is consumed on the next), but the asymmetry with the legacy path is unintentional. Drop the L2887 line — Python's function scope means last_error is already in scope:

            if parsed.get("tool_calls"):
                tc_list = parsed["tool_calls"]
                any_error = False
                fanout_repeat_break = False

🟢 Minor — STATE_COMPLETION flip for single-step plans skipped in fan-out (src/gaia/agents/base/agent.py:2884)

The legacy path at L3070-3075 sets self.execution_state = self.STATE_COMPLETION when total_plan_steps == 1 before executing the tool. The fan-out skips this. With this PR, single native calls (len(tool_calls) == 1) flow through the fan-out instead of the legacy path, so a single-step plan that resolves to a single native tool_call no longer flips to STATE_COMPLETION. The downstream comment at L3179-3188 says "Don't break here — let the loop continue so the LLM can process the tool result", suggesting the flip mostly drives bookkeeping rather than control flow, but a one-line if len(tc_list) == 1 and self.total_plan_steps == 1: self.execution_state = self.STATE_COMPLETION near L2890 would preserve parity. Worth verifying with an existing single-step-plan test before merge.

🟢 Minor — _register_tool test helper bypasses the @tool decorator (tests/unit/agents/test_parallel_tool_calls.py:75-85)

The fixture injects directly into _TOOL_REGISTRY with "parameters": {} and "atomic": False, sidestepping any normalisation @tool performs. Today the agent's tool-execution path doesn't depend on extra fields, but if @tool ever adds e.g. JSON-schema validation or argument coercion, these tests will silently diverge from real-world behaviour. Either:

• Use @tool directly in the test (preferred — it's what production code does), or
• Add a comment in the helper explicitly noting the intentional bypass and what's being skipped.

Strengths

• Backward-compat shape is well-thought-through. The N==1 native path populates both the new tool_calls list (real id, correlated result) and the legacy tool/tool_args fields, then gates the legacy execution branch on not parsed.get("tool_calls") (agent.py:3053) so single calls still get the new id-correlated result message without breaking embedded-JSON consumers. Documented in the docstring at agent.py:944-958.
• Defensive parsing. Each tool_call entry is normalised independently (agent.py:1004-1035), so one bad-arguments entry only poisons that call's parse, not the others. Synthesised id when llama.cpp omits one (agent.py:1034) is a nice belt-and-braces — and the corresponding test (test_parse_native_synthesises_id_when_missing) pins it.
• Empty tool_calls list now raises (agent.py:994-997) instead of silently tool_calls[0]-indexing — aligns with CLAUDE.md's no-silent-fallbacks rule.
• _build_assistant_message factored out (agent.py:1677-1715) removes duplication on the assistant-message side and is correctly applied to both the main response path and the planner path (be24697). The docstring explains why the OpenAI shape matters — spec-strict providers reject the raw sentinel envelope as content.
• Content carry-through with reasoning_content fallback (lemonade.py:310-315) catches the llama.cpp variant where assistant text lands in reasoning_content instead of content — a real-world quirk worth pinning.
• Test pins the acceptance criteria, not just happy paths. test_three_calls_one_errors_all_drain enforces the "drain all N before recovery" contract; test_no_malformed_arguments_prompt_injected is a regression guard against the exact symptom in the issue.

Verdict

Approve with suggestions — the 🟡 items are real concerns but none are blockers. The duplication issue is best handled in a follow-up; the plan-priority asymmetry and last_error reset are easy in-PR cleanups if the author wants to land them now. Tests are strong, motivation is clear, and the OpenAI-shape correctness work is exactly the right fix.

Should I close my pull request at #945 because I don't want to add any confusion to this

Didn't realize you fixed it, you can complete yours since you already pushed a fix before me.

Should I close my pull request at #945 because I don't want to add any confusion to this

Didn't realize you fixed it, you can complete yours since you already pushed a fix before me.

yea I saw it the second you posted and attempted to tackle it I can close my PR if you want though I don't want to cause much confusion