compat: treat natural no_tool finish as a complete run

[dappweb]

Summary

Two parity gaps break the stateful react workflow for OpenAI-compatible models that end a task with a plain-text answer instead of a final tool call. Reproduced with a local Qwen3.5-family endpoint (qwen3.8-27b via Ollama /v1).

Changes

1. workflows/stateful_react_agent/_runtime.py — add no_tool to _GRACEFUL_FINAL_STOP_REASONS so force_final_answer() rescue runs when the loop ends naturally after the model has already produced its answer.
2. apodex/task_runner.py — pass no_tool_is_complete=True in the native-workflow completion check, matching the generic-loop path (which already passes it).

Verification

• Before: local qwen3.8-27b-fast completes the task (reads input, writes deliverable content) but the run is reported as run incomplete · stopped_by=no_tool · partial output was not saved as a final report.
• After: same run completes and the final report is rendered/saved.

Notes

• Generic loop already passes no_tool_is_complete=True; this makes the native workflow consistent.
• No behavior change for workflows that finish via explicit final-answer tools.

[zhanghanduo]

Thanks for the attempt to fix.

I think the reported issue is valid, but the root cause is that no_tool is overloaded: depending on the workflow, it can mean a successful plain-text answer, an empty response, a tool-protocol violation, or exhausted nudge retries.

In stateful_react, no_tool_behavior="stop", so a non-empty plain-text response is already a successful final answer. In agent_team, non-empty text is finalized by BareTextFinalizeObserver, while no_tool usually means empty-response retries were exhausted.

Therefore, globally treating no_tool as complete is unsafe, and routing it through force_final_answer() adds an unnecessary LLM call that can rewrite the answer and mark it as best_effort.

I suggest introducing explicit stop reasons such as plain_text_final and empty_response_retries_exhausted, or having each workflow return an authoritative completion status. That would address the root cause instead of making TaskRunner infer completion from the ambiguous no_tool value.

[zhanghanduo]

The reported stateful_react issue is valid, but this fix is too broad.

Passing no_tool_is_complete=True from _run_native_workflow() makes every
native-workflow stopped_by="no_tool" a completed delivery, even though
no_tool is not a uniform success signal across workflows.

In agent_team, successful plain-text completion is converted to
final_answer by BareTextFinalizeObserver. The remaining no_tool cases
typically represent exhausted empty-response/nudge retries and are incomplete.
Marking them complete would regress the behavior covered by:

apodex/tests/test_features.py::test_native_workflow_no_tool_stop_is_not_reported_as_delivery

Please distinguish successful plain-text completion from exhausted no-tool
retries—through explicit stop reasons or an authoritative workflow completion
status—rather than treating no_tool as globally successful.

[dappweb]

Summary

Two parity gaps break the stateful react workflow for OpenAI-compatible models that end a task with a plain-text answer instead of a final tool call. Reproduced with a local Qwen3.5-family endpoint (qwen3.8-27b via Ollama /v1).

Changes

1. workflows/stateful_react_agent/_runtime.py — add no_tool to _GRACEFUL_FINAL_STOP_REASONS so force_final_answer() rescue runs when the loop ends naturally after the model has already produced its answer.
2. apodex/task_runner.py — pass no_tool_is_complete=True in the native-workflow completion check, matching the generic-loop path (which already passes it).

Verification

• Before: local qwen3.8-27b-fast completes the task (reads input, writes deliverable content) but the run is reported as run incomplete · stopped_by=no_tool · partial output was not saved as a final report.
• After: same run completes and the final report is rendered/saved.

Notes

• Generic loop already passes no_tool_is_complete=True; this makes the native workflow consistent.
• No behavior change for workflows that finish via explicit final-answer tools.

[zhanghanduo]

Thanks for the attempt to fix.

I think the reported issue is valid, but the root cause is that no_tool is overloaded: depending on the workflow, it can mean a successful plain-text answer, an empty response, a tool-protocol violation, or exhausted nudge retries.

In stateful_react, no_tool_behavior="stop", so a non-empty plain-text response is already a successful final answer. In agent_team, non-empty text is finalized by BareTextFinalizeObserver, while no_tool usually means empty-response retries were exhausted.

Therefore, globally treating no_tool as complete is unsafe, and routing it through force_final_answer() adds an unnecessary LLM call that can rewrite the answer and mark it as best_effort.

I suggest introducing explicit stop reasons such as plain_text_final and empty_response_retries_exhausted, or having each workflow return an authoritative completion status. That would address the root cause instead of making TaskRunner infer completion from the ambiguous no_tool value.

[zhanghanduo]

The reported stateful_react issue is valid, but this fix is too broad.

Passing no_tool_is_complete=True from _run_native_workflow() makes every
native-workflow stopped_by="no_tool" a completed delivery, even though
no_tool is not a uniform success signal across workflows.

In agent_team, successful plain-text completion is converted to
final_answer by BareTextFinalizeObserver. The remaining no_tool cases
typically represent exhausted empty-response/nudge retries and are incomplete.
Marking them complete would regress the behavior covered by:

apodex/tests/test_features.py::test_native_workflow_no_tool_stop_is_not_reported_as_delivery

Please distinguish successful plain-text completion from exhausted no-tool
retries—through explicit stop reasons or an authoritative workflow completion
status—rather than treating no_tool as globally successful.

[dappweb]

Summary

Two parity gaps break the stateful react workflow for OpenAI-compatible models that end a task with a plain-text answer instead of a final tool call. Reproduced with a local Qwen3.5-family endpoint (qwen3.8-27b via Ollama /v1).

Changes

1. workflows/stateful_react_agent/_runtime.py — add no_tool to _GRACEFUL_FINAL_STOP_REASONS so force_final_answer() rescue runs when the loop ends naturally after the model has already produced its answer.
2. apodex/task_runner.py — pass no_tool_is_complete=True in the native-workflow completion check, matching the generic-loop path (which already passes it).

Verification

• Before: local qwen3.8-27b-fast completes the task (reads input, writes deliverable content) but the run is reported as run incomplete · stopped_by=no_tool · partial output was not saved as a final report.
• After: same run completes and the final report is rendered/saved.

Notes

• Generic loop already passes no_tool_is_complete=True; this makes the native workflow consistent.
• No behavior change for workflows that finish via explicit final-answer tools.

[zhanghanduo]

Thanks for the attempt to fix.

I think the reported issue is valid, but the root cause is that no_tool is overloaded: depending on the workflow, it can mean a successful plain-text answer, an empty response, a tool-protocol violation, or exhausted nudge retries.

In stateful_react, no_tool_behavior="stop", so a non-empty plain-text response is already a successful final answer. In agent_team, non-empty text is finalized by BareTextFinalizeObserver, while no_tool usually means empty-response retries were exhausted.

Therefore, globally treating no_tool as complete is unsafe, and routing it through force_final_answer() adds an unnecessary LLM call that can rewrite the answer and mark it as best_effort.

I suggest introducing explicit stop reasons such as plain_text_final and empty_response_retries_exhausted, or having each workflow return an authoritative completion status. That would address the root cause instead of making TaskRunner infer completion from the ambiguous no_tool value.

[zhanghanduo]

The reported stateful_react issue is valid, but this fix is too broad.

Passing no_tool_is_complete=True from _run_native_workflow() makes every
native-workflow stopped_by="no_tool" a completed delivery, even though
no_tool is not a uniform success signal across workflows.

In agent_team, successful plain-text completion is converted to
final_answer by BareTextFinalizeObserver. The remaining no_tool cases
typically represent exhausted empty-response/nudge retries and are incomplete.
Marking them complete would regress the behavior covered by:

apodex/tests/test_features.py::test_native_workflow_no_tool_stop_is_not_reported_as_delivery

Please distinguish successful plain-text completion from exhausted no-tool
retries—through explicit stop reasons or an authoritative workflow completion
status—rather than treating no_tool as globally successful.

[dappweb]

Summary

Two parity gaps break the stateful react workflow for OpenAI-compatible models that end a task with a plain-text answer instead of a final tool call. Reproduced with a local Qwen3.5-family endpoint (qwen3.8-27b via Ollama /v1).

Changes

1. workflows/stateful_react_agent/_runtime.py — add no_tool to _GRACEFUL_FINAL_STOP_REASONS so force_final_answer() rescue runs when the loop ends naturally after the model has already produced its answer.
2. apodex/task_runner.py — pass no_tool_is_complete=True in the native-workflow completion check, matching the generic-loop path (which already passes it).

Verification

• Before: local qwen3.8-27b-fast completes the task (reads input, writes deliverable content) but the run is reported as run incomplete · stopped_by=no_tool · partial output was not saved as a final report.
• After: same run completes and the final report is rendered/saved.

Notes

• Generic loop already passes no_tool_is_complete=True; this makes the native workflow consistent.
• No behavior change for workflows that finish via explicit final-answer tools.

[zhanghanduo]

Thanks for the attempt to fix.

I think the reported issue is valid, but the root cause is that no_tool is overloaded: depending on the workflow, it can mean a successful plain-text answer, an empty response, a tool-protocol violation, or exhausted nudge retries.

In stateful_react, no_tool_behavior="stop", so a non-empty plain-text response is already a successful final answer. In agent_team, non-empty text is finalized by BareTextFinalizeObserver, while no_tool usually means empty-response retries were exhausted.

Therefore, globally treating no_tool as complete is unsafe, and routing it through force_final_answer() adds an unnecessary LLM call that can rewrite the answer and mark it as best_effort.

I suggest introducing explicit stop reasons such as plain_text_final and empty_response_retries_exhausted, or having each workflow return an authoritative completion status. That would address the root cause instead of making TaskRunner infer completion from the ambiguous no_tool value.

[zhanghanduo]

The reported stateful_react issue is valid, but this fix is too broad.

Passing no_tool_is_complete=True from _run_native_workflow() makes every
native-workflow stopped_by="no_tool" a completed delivery, even though
no_tool is not a uniform success signal across workflows.

In agent_team, successful plain-text completion is converted to
final_answer by BareTextFinalizeObserver. The remaining no_tool cases
typically represent exhausted empty-response/nudge retries and are incomplete.
Marking them complete would regress the behavior covered by:

apodex/tests/test_features.py::test_native_workflow_no_tool_stop_is_not_reported_as_delivery

Please distinguish successful plain-text completion from exhausted no-tool
retries—through explicit stop reasons or an authoritative workflow completion
status—rather than treating no_tool as globally successful.

[dappweb]

Summary

Two parity gaps break the stateful react workflow for OpenAI-compatible models that end a task with a plain-text answer instead of a final tool call. Reproduced with a local Qwen3.5-family endpoint (qwen3.8-27b via Ollama /v1).

Changes

1. workflows/stateful_react_agent/_runtime.py — add no_tool to _GRACEFUL_FINAL_STOP_REASONS so force_final_answer() rescue runs when the loop ends naturally after the model has already produced its answer.
2. apodex/task_runner.py — pass no_tool_is_complete=True in the native-workflow completion check, matching the generic-loop path (which already passes it).

Verification

• Before: local qwen3.8-27b-fast completes the task (reads input, writes deliverable content) but the run is reported as run incomplete · stopped_by=no_tool · partial output was not saved as a final report.
• After: same run completes and the final report is rendered/saved.

Notes

• Generic loop already passes no_tool_is_complete=True; this makes the native workflow consistent.
• No behavior change for workflows that finish via explicit final-answer tools.

[zhanghanduo]

Thanks for the attempt to fix.

I think the reported issue is valid, but the root cause is that no_tool is overloaded: depending on the workflow, it can mean a successful plain-text answer, an empty response, a tool-protocol violation, or exhausted nudge retries.

In stateful_react, no_tool_behavior="stop", so a non-empty plain-text response is already a successful final answer. In agent_team, non-empty text is finalized by BareTextFinalizeObserver, while no_tool usually means empty-response retries were exhausted.

Therefore, globally treating no_tool as complete is unsafe, and routing it through force_final_answer() adds an unnecessary LLM call that can rewrite the answer and mark it as best_effort.

I suggest introducing explicit stop reasons such as plain_text_final and empty_response_retries_exhausted, or having each workflow return an authoritative completion status. That would address the root cause instead of making TaskRunner infer completion from the ambiguous no_tool value.

[zhanghanduo]

The reported stateful_react issue is valid, but this fix is too broad.

Passing no_tool_is_complete=True from _run_native_workflow() makes every
native-workflow stopped_by="no_tool" a completed delivery, even though
no_tool is not a uniform success signal across workflows.

In agent_team, successful plain-text completion is converted to
final_answer by BareTextFinalizeObserver. The remaining no_tool cases
typically represent exhausted empty-response/nudge retries and are incomplete.
Marking them complete would regress the behavior covered by:

apodex/tests/test_features.py::test_native_workflow_no_tool_stop_is_not_reported_as_delivery

Please distinguish successful plain-text completion from exhausted no-tool
retries—through explicit stop reasons or an authoritative workflow completion
status—rather than treating no_tool as globally successful.

[dappweb]

Summary

Two parity gaps break the stateful react workflow for OpenAI-compatible models that end a task with a plain-text answer instead of a final tool call. Reproduced with a local Qwen3.5-family endpoint (qwen3.8-27b via Ollama /v1).

Changes

1. workflows/stateful_react_agent/_runtime.py — add no_tool to _GRACEFUL_FINAL_STOP_REASONS so force_final_answer() rescue runs when the loop ends naturally after the model has already produced its answer.
2. apodex/task_runner.py — pass no_tool_is_complete=True in the native-workflow completion check, matching the generic-loop path (which already passes it).

Verification

• Before: local qwen3.8-27b-fast completes the task (reads input, writes deliverable content) but the run is reported as run incomplete · stopped_by=no_tool · partial output was not saved as a final report.
• After: same run completes and the final report is rendered/saved.

Notes

• Generic loop already passes no_tool_is_complete=True; this makes the native workflow consistent.
• No behavior change for workflows that finish via explicit final-answer tools.

[zhanghanduo]

Thanks for the attempt to fix.

I think the reported issue is valid, but the root cause is that no_tool is overloaded: depending on the workflow, it can mean a successful plain-text answer, an empty response, a tool-protocol violation, or exhausted nudge retries.

In stateful_react, no_tool_behavior="stop", so a non-empty plain-text response is already a successful final answer. In agent_team, non-empty text is finalized by BareTextFinalizeObserver, while no_tool usually means empty-response retries were exhausted.

Therefore, globally treating no_tool as complete is unsafe, and routing it through force_final_answer() adds an unnecessary LLM call that can rewrite the answer and mark it as best_effort.

I suggest introducing explicit stop reasons such as plain_text_final and empty_response_retries_exhausted, or having each workflow return an authoritative completion status. That would address the root cause instead of making TaskRunner infer completion from the ambiguous no_tool value.

[zhanghanduo]

The reported stateful_react issue is valid, but this fix is too broad.

Passing no_tool_is_complete=True from _run_native_workflow() makes every
native-workflow stopped_by="no_tool" a completed delivery, even though
no_tool is not a uniform success signal across workflows.

In agent_team, successful plain-text completion is converted to
final_answer by BareTextFinalizeObserver. The remaining no_tool cases
typically represent exhausted empty-response/nudge retries and are incomplete.
Marking them complete would regress the behavior covered by:

apodex/tests/test_features.py::test_native_workflow_no_tool_stop_is_not_reported_as_delivery

Please distinguish successful plain-text completion from exhausted no-tool
retries—through explicit stop reasons or an authoritative workflow completion
status—rather than treating no_tool as globally successful.

[dappweb]

Summary

Two parity gaps break the stateful react workflow for OpenAI-compatible models that end a task with a plain-text answer instead of a final tool call. Reproduced with a local Qwen3.5-family endpoint (qwen3.8-27b via Ollama /v1).

Changes

1. workflows/stateful_react_agent/_runtime.py — add no_tool to _GRACEFUL_FINAL_STOP_REASONS so force_final_answer() rescue runs when the loop ends naturally after the model has already produced its answer.
2. apodex/task_runner.py — pass no_tool_is_complete=True in the native-workflow completion check, matching the generic-loop path (which already passes it).

Verification

• Before: local qwen3.8-27b-fast completes the task (reads input, writes deliverable content) but the run is reported as run incomplete · stopped_by=no_tool · partial output was not saved as a final report.
• After: same run completes and the final report is rendered/saved.

Notes

• Generic loop already passes no_tool_is_complete=True; this makes the native workflow consistent.
• No behavior change for workflows that finish via explicit final-answer tools.

[zhanghanduo]

Thanks for the attempt to fix.

I think the reported issue is valid, but the root cause is that no_tool is overloaded: depending on the workflow, it can mean a successful plain-text answer, an empty response, a tool-protocol violation, or exhausted nudge retries.

In stateful_react, no_tool_behavior="stop", so a non-empty plain-text response is already a successful final answer. In agent_team, non-empty text is finalized by BareTextFinalizeObserver, while no_tool usually means empty-response retries were exhausted.

Therefore, globally treating no_tool as complete is unsafe, and routing it through force_final_answer() adds an unnecessary LLM call that can rewrite the answer and mark it as best_effort.

I suggest introducing explicit stop reasons such as plain_text_final and empty_response_retries_exhausted, or having each workflow return an authoritative completion status. That would address the root cause instead of making TaskRunner infer completion from the ambiguous no_tool value.

[zhanghanduo]

The reported stateful_react issue is valid, but this fix is too broad.

Passing no_tool_is_complete=True from _run_native_workflow() makes every
native-workflow stopped_by="no_tool" a completed delivery, even though
no_tool is not a uniform success signal across workflows.

In agent_team, successful plain-text completion is converted to
final_answer by BareTextFinalizeObserver. The remaining no_tool cases
typically represent exhausted empty-response/nudge retries and are incomplete.
Marking them complete would regress the behavior covered by:

apodex/tests/test_features.py::test_native_workflow_no_tool_stop_is_not_reported_as_delivery

Please distinguish successful plain-text completion from exhausted no-tool
retries—through explicit stop reasons or an authoritative workflow completion
status—rather than treating no_tool as globally successful.

[dappweb]

Summary

Two parity gaps break the stateful react workflow for OpenAI-compatible models that end a task with a plain-text answer instead of a final tool call. Reproduced with a local Qwen3.5-family endpoint (qwen3.8-27b via Ollama /v1).

Changes

1. workflows/stateful_react_agent/_runtime.py — add no_tool to _GRACEFUL_FINAL_STOP_REASONS so force_final_answer() rescue runs when the loop ends naturally after the model has already produced its answer.
2. apodex/task_runner.py — pass no_tool_is_complete=True in the native-workflow completion check, matching the generic-loop path (which already passes it).

Verification

• Before: local qwen3.8-27b-fast completes the task (reads input, writes deliverable content) but the run is reported as run incomplete · stopped_by=no_tool · partial output was not saved as a final report.
• After: same run completes and the final report is rendered/saved.

Notes

• Generic loop already passes no_tool_is_complete=True; this makes the native workflow consistent.
• No behavior change for workflows that finish via explicit final-answer tools.

[zhanghanduo]

Thanks for the attempt to fix.

I think the reported issue is valid, but the root cause is that no_tool is overloaded: depending on the workflow, it can mean a successful plain-text answer, an empty response, a tool-protocol violation, or exhausted nudge retries.

In stateful_react, no_tool_behavior="stop", so a non-empty plain-text response is already a successful final answer. In agent_team, non-empty text is finalized by BareTextFinalizeObserver, while no_tool usually means empty-response retries were exhausted.

Therefore, globally treating no_tool as complete is unsafe, and routing it through force_final_answer() adds an unnecessary LLM call that can rewrite the answer and mark it as best_effort.

I suggest introducing explicit stop reasons such as plain_text_final and empty_response_retries_exhausted, or having each workflow return an authoritative completion status. That would address the root cause instead of making TaskRunner infer completion from the ambiguous no_tool value.

[zhanghanduo]

The reported stateful_react issue is valid, but this fix is too broad.

Passing no_tool_is_complete=True from _run_native_workflow() makes every
native-workflow stopped_by="no_tool" a completed delivery, even though
no_tool is not a uniform success signal across workflows.

In agent_team, successful plain-text completion is converted to
final_answer by BareTextFinalizeObserver. The remaining no_tool cases
typically represent exhausted empty-response/nudge retries and are incomplete.
Marking them complete would regress the behavior covered by:

apodex/tests/test_features.py::test_native_workflow_no_tool_stop_is_not_reported_as_delivery

Please distinguish successful plain-text completion from exhausted no-tool
retries—through explicit stop reasons or an authoritative workflow completion
status—rather than treating no_tool as globally successful.