📄 api/core/agent/base_agent_runner.py:502

The ToolPromptMessage content was changed from tool_responses.get(tool, agent_thought.observation) to str(tool_inputs.get(tool, agent_thought.observation)). This means that when reconstructing conversation history, tool call responses will now contain tool inputs (the arguments sent to the tool) instead of the actual tool outputs/observations.

This corrupts the agent's conversation history, causing the LLM to see tool inputs where it should see tool results. This will lead to incorrect agent behavior in multi-turn conversations that reference prior tool usage.

The original code using tool_responses was correct. The variable tool_responses is parsed from agent_thought.observation (the tool's output), which is the right data to put in a ToolPromptMessage.

                                    content=str(tool_responses.get(tool, agent_thought.observation)),

📄 api/core/agent/base_agent_runner.py:325 📄 api/core/agent/base_agent_runner.py:326

The initial values for answer_unit_price and answer_price_unit are swapped compared to their message_* counterparts:

message_unit_price=Decimal(0),        # ✅ unit price starts at 0
message_price_unit=Decimal("0.001"),  # ✅ price unit = per 1000 tokens
answer_unit_price=Decimal("0.001"),   # ❌ should be Decimal(0)
answer_price_unit=Decimal(0),         # ❌ should be Decimal("0.001")

The semantics of *_unit_price (the cost per token) and *_price_unit (the denomination, e.g., per 1000 tokens) should be consistent between message and answer. The model's server_default for answer_price_unit is sa.text("0.001"), confirming that price_unit should be 0.001, not 0.

These values are later overwritten by actual LLM usage data (llm_usage.completion_unit_price / llm_usage.completion_price_unit), so the impact is limited to the brief window between creation and the update. However, if the update fails or is skipped, the swapped defaults would result in incorrect cost calculations.

            answer_unit_price=Decimal(0),
            answer_price_unit=Decimal("0.001"),

📄 api/core/agent/base_agent_runner.py:328

The total_price field is typed as Mapped[Decimal | None] in the model, but total_price=0 passes a plain int. While SQLAlchemy can coerce this, it's inconsistent with the other price fields which explicitly use Decimal(0). This was previously Decimal(0) and was regressed in this PR.

For consistency and to avoid any potential type-checking issues with the new TypeBase (MappedAsDataclass) approach, this should use Decimal(0).

            total_price=Decimal(0),

📄 api/core/agent/base_agent_runner.py:52

The AgentThoughtValidation Pydantic model is defined (lines 52-65) but is never referenced anywhere in this file or elsewhere in the codebase. It also has a self-contradicting comment: extra = "allow" with a comment saying # Pydantic v1 syntax - should use ConfigDict(extra='forbid') — the comment suggests "forbid" but the code uses "allow", and indeed the syntax is Pydantic v1 while the project likely uses Pydantic v2.

If this is intended for future use, consider adding it in the PR that actually uses it. Dead code adds maintenance burden and confusion.

📄 api/core/agent/base_agent_runner.py:485

On line 485, when observation_payload is falsy (None or empty string), the code does:

tool_responses = dict.fromkeys(tool_names, observation_payload)

This creates a dict where all values are None (since observation_payload is falsy). Later, tool_responses is used in the ToolPromptMessage content (assuming the tool_inputs → tool_responses fix is applied). Passing None as content could cause issues downstream.

The original code had the same behavior on the exception branch (dict.fromkeys(tools, agent_thought.observation) where observation could be None), so this is a pre-existing edge case, but the explicit null-check structure makes it a good opportunity to provide a safer fallback like "" instead of None.

                        else:
                            tool_responses = dict.fromkeys(tool_names, "")