Protocol routing drops session context for follow-up queries and blocks data tools

[iancaoo]

Summary

Protocol routing currently classifies each new run using only the latest user query. It does not include relevant session context such as the previous user request, the previous run protocol, the selected data-analysis skill, or the selected datasource.

As a result, short follow-up prompts such as 再次尝试 ("try again") can be routed to general-task, even when they clearly continue a data-analysis workflow. The agent later receives the conversation history and attempts to call data tools, but the protocol boundary rejects them.

Reproduction

1. Start a session with a configured datasource and the data-analysis skill.
2. Send 帮我分析当前数据 ("analyze the current data").
3. After that run ends or fails, send 再次尝试 ("try again") in the same session.
4. Observe the protocol and tool events.

Actual behavior

The follow-up run is routed as:

protocolId: general-task
source: default
warning: PROTOCOL_CLASSIFICATION_LOW_CONFIDENCE
phase: understand

The agent can see the conversation history and attempts to continue the analysis, but data tools are rejected before execution:

ACTION_NOT_ALLOWED_IN_PHASE
Tool inspect_schema is not allowed in protocol phase understand.
executionStatus: not_started

In the observed run:

• inspect_schema was rejected 3 times.
• list_data_sources was rejected once.
• The datasource was never called.
• The run was ultimately marked completed only because the agent committed a text response explaining that it could not continue.

Root cause

createRunProtocolBoundary passes only the current input to both routing paths:

analyticIntent(input.userInput)
classificationInput: { userText: input.userInput }

The model classifier therefore sees only the ambiguous follow-up text. Conversation history is provided later to the execution agent through governedMessages, after the protocol has already been selected.

This creates a context split:

• Protocol classifier: sees only 再次尝试 and selects general-task.
• Execution agent: sees the session history and attempts data analysis.
• Protocol governor: rejects the data tools because general-task excludes data actions.

Expected behavior

Follow-up prompts that depend on prior session intent should preserve or infer the relevant protocol context. In this case, 再次尝试 should continue with data-analysis, and inspect_schema should be allowed in the initial data-analysis phase.

Suggested direction

Provide a compact routing context containing:

• Current user query.
• Previous meaningful user query.
• Previous run protocol and terminal status.
• Selected skill IDs.
• Selected datasource ID.

For weak follow-up intents such as "continue", "retry", or "try again", prefer inheriting the previous compatible protocol unless the user explicitly changes the task.

Also add a consistency guard so a run cannot expose a data-analysis tool policy while being governed by a protocol that rejects every data action.