Combining EngramState with structured decoding

Reusable state answers “what tool knowledge should the model remember?” Structured decoding answers “what outputs are syntactically allowed?” They solve different problems and can work together.

Why the original gain looked small

On DroidCall, the fine-tuned model had already learned much of the expected function-call syntax. Adding a grammar constraint therefore had limited room to improve formatting.

Change the required output format

To isolate the role of constrained decoding, we changed the required output to JSON without additional syntax-constraint training. This creates a setting where the semantic tool knowledge can still be useful while the exact output grammar is unfamiliar.

MethodDecodingValid JSONAccuracy
Prompt (Top-4)Free0.2000.125
Prompt (Top-4)XGrammar20.9900.595
EngramStateFree0.6450.410
EngramStateXGrammar20.9800.615
Interpretation: the state can carry semantic tool knowledge while XGrammar2 enforces the required syntax. When output format changes, the two mechanisms are complementary rather than redundant.

Where structured decoding helps most

The combination is especially useful for errors that are fundamentally syntactic or schema-driven: malformed JSON, missing braces, invalid keys, or strict type/enum constraints. It is less likely to fix semantic errors such as choosing the wrong tool or inventing the wrong parameter value.

A clean systems decomposition

Retriever + EngramState
    → choose / restore semantic tool knowledge

Structured decoder
    → constrain legal output form

Validator
    → inspect semantic + execution correctness

This separation also makes the agent easier to reason about: retrieval, memory, syntax, and execution validation each have a distinct responsibility.

← Back to technical notes