Incremental updates are tool-local
Because EngramState stores independent tool artifacts, a tool edit does not require recompiling the entire repository.
- Updated tool: recompile only its Base + Corrective states. For RWKV-7 1.5B, the pair takes about 0.28 s.
- New tool: compile only the new states, leave existing states untouched, then update the retriever with data for the new tool.
- Deleted tool: remove the state files and retriever entry.
In the DroidCall retriever setup, training 24 tools / 240 examples for 50 epochs takes roughly 10–13 s on one RTX 3090. The exact incremental retriever cost depends on the update procedure and data volume, but the key point is that state compilation itself remains local to the changed tool.
When must every state be regenerated?
Changing the backbone is different. Recurrent state shape depends on model architecture, layer count, and state dimensions. A state compiled for RWKV-7 1.5B cannot be directly loaded into a 2.9B backbone. The tool state must be recompiled using the new model, although that does not require an additional round of model fine-tuning.
Why not precompile every tool combination?
A natural idea for multi-tool requests is to combine related tools into one composite state. We tested this by jointly compiling two or three tool APIs into a single state.
| Method | Soft Accuracy | Exact Accuracy |
|---|---|---|
| Jointly compiled multi-tool state | 0.825 | 0.700 |
| Decomposed user query | 0.904 | 0.795 |
Joint compilation works, but the number of possible combinations grows combinatorially with the repository. Exhaustively storing every useful combination is therefore unattractive.
Current multi-call strategy
The current implementation keeps independent per-tool states and traverses the same Top-K candidate list across calls. If the first candidate fails and the second succeeds, that success becomes the first call, and the executor continues from the third candidate when additional calls are needed. It does not restart retrieval from the beginning.
Query decomposition
For more complex requests, another strategy is to decompose the user request into sequential sub-tasks and load the relevant state for each call. In our experiment, this produced 0.904 Soft Accuracy and 0.795 Exact Accuracy, slightly above the fixed Top-K prompt baseline reported in the same discussion.