Know2Act: What Knowledge Reaches
a Tool-Using Agent’s Actions?

Key numbers

Qwen3-4B student, Qwen3-32B teacher, SkyRL text-to-SQL environment; evaluation on Spider-dev and BIRD-dev with 16 samples per question; 95% intervals from a bootstrap over questions.

The question

A tool-using agent’s trajectory interleaves decisions with their consequences: it issues a query, the environment returns a result, and the agent decides what to do next. Standard supervised fine-tuning puts the loss on the agent’s actions only. ActObs (Zhang et al., 2026) removes this mask and also trains the agent to predict the observations. It reports that GRPO then reaches higher pass@k on Terminal-Bench, and attributes the gain to the agent learning what its actions do.

That explanation has a testable step in the middle. For a predictive objective to help, what the model learns must change what it does, and that link has not been measured. We measure it at three levels: whether the knowledge is learned, whether it moves the action distribution, and whether it changes the one decision a SQL agent makes after every result, namely to submit an answer or to keep querying.

Training variants

All variants train on the same 24,043 teacher trajectories, in the same order and with the same hyper-parameters, and then go through the same GRPO. They differ only in which tokens carry loss or in a short line inserted into the text. The main study was pre-registered, and the predictions for the later variants were written down before they were trained.

Findings

RQ1Does observation supervision make RL stronger? No. Before RL all variants are within about one point of each other. After the same GRPO, ActObs and ActionSFT reach the same pooled pass@16 (+0.26 points, 95% CI [−0.38, +0.91], averaged over two RL seeds of each), and GRPO extracts no consistently larger gain from ActObs than from the action-only models.

RQ2What does the model learn, and does it reach the actions? It learns the observations’ structure but not their content. On databases it never saw, ActObs predicts the output template almost perfectly and the result header far better than ActionSFT, yet predicts row values no better (1.92 vs. 1.88 nats). Its action distribution differs from ActionSFT’s by less than two action-only models trained on reshuffled data differ from each other, and its behaviour after errors and empty results is unchanged.

RQ3Does it matter what the agent predicts and where? For the action tokens, yes. The same outcome line moves the action distribution only when it is written inside the action (2.3 times the noise floor); as an auxiliary target it does not. The contract is learned on unseen databases and states the correct answer shape in 89% (Spider) and 82% (BIRD) of rollouts, against 71% and 49% for a classifier that reads only the question.

RQ4Does any of it change the agent’s decisions? No. After every result the agent either submits or keeps querying. We measure how much more often it submits when the result has the right shape than when it does not. ActionSFT already shows this asymmetry, inherited from the teacher, and no variant changes it by more than retraining ActionSFT on a reshuffled data order does. This holds even for Contract, whose own check reports every mismatch in words.

RQ5Can the knowledge be used from outside? Before RL, yes. Picking among 16 sampled answers by the contract beats a filter that drops errors and empty results, and adds to execution majority voting. After GRPO, it adds nothing: RL has already removed most of the shape errors a contract would catch.

Accuracy (%) on the primary questions. The contracts come from the Contract model and are applied to ActionSFT’s samples, so the selector uses knowledge that ActionSFT itself never had.

What the agent writes

Three real rollouts on Spider-dev. Inserted lines are in purple, queries in blue and observations on grey; […] and ... mark text we shortened.

Expected answer: 1 row, 1 column.
<sql>SELECT Population FROM city WHERE District = 'Gelderland';</sql>
152463 / 101574 / 138020 / 153491
Check: got several rows, 1 column; this does not match the expected answer. […] Since the question asks for the total number of people living in the district, we need to sum these values.
<sql>SELECT SUM(Population) FROM city WHERE District = 'Gelderland';</sql>
545548
Check: got 1 row, 1 column; this matches the expected answer.
<solution>SELECT SUM(Population) FROM city WHERE District = 'Gelderland';</solution>

Expected answer: 1 row, 1 column.
<sql>SELECT * FROM Paragraphs WHERE Paragraph_Text = 'Korea';</sql>
510442723 2394 Korea None / 7 2394 Korea None
Check: got several rows, 4 columns; this does not match the expected answer.
<solution>SELECT * FROM Paragraphs WHERE Paragraph_Text = 'Korea';</solution>

Expected result: 10 rows, 1 column.
<sql>SELECT p.Name FROM poker_player p JOIN people p2 ON ...;</sql>
Error executing SQL: no such column: p.Name
Expected result: 10 rows, 1 column.
<sql>SELECT p2.Name FROM poker_player p JOIN people p2 ON ...;</sql>
Aleksey Ostapenko / Yevgeni Sivozhelez / ... (5 rows)
<solution>SELECT p2.Name FROM poker_player p JOIN people p2 ON ...;</solution>

Environment audit

The public SkyRL text-to-SQL environment rewards a solution when its result set equals the gold query’s. Running the unmodified environment with the constant answer SELECT 1 WHERE 0; earns full reward on 290 of its 653 training tasks (44%): 283 of the 540 SynSQL tasks and 7 of the 113 Spider tasks. Their gold queries return no rows, and for 18 of them the result depends on the system clock through filters such as year > strftime('%Y','now') - 5. We train RL only on the 363 tasks with non-empty gold results, and reported the problem to the maintainers with a reproduction script (SkyRL issue #2451).

BibTeX

Copy@misc{lu2026know2act,
  title  = {Know2Act: What Knowledge Reaches a Tool-Using Agent's Actions?},
  author = {Lu, Yiwen},
  year   = {2026},
  note   = {Manuscript}
}