Helpers for Jido.AI.Reasoning.ReAct consumers that want Gralkor-aware
request shaping.
maybe_force_memory_search/2 pins tool_choice to the memory_search
tool on the first ReAct iteration so the agent itself authors a focused
search query (in the same thread, with the same model, as part of the
same turn) rather than the harness embedding raw user text against the
graph. From iteration 2 onward the override is omitted so the model is
free to answer or call further tools.
Workaround: Jido.AI.Reasoning.ReAct.Config.tool_choice is one value
applied uniformly across the loop. Returning the override per-iteration
through RequestTransformer is the cheapest way to vary it without
forking the strategy. A first-class :preamble_tool config in ReAct
would supersede this.
Summary
Functions
Fold the iter-1 tool_choice: {:tool, "memory_search"} override into
the consumer's existing transformer overrides map.
Functions
@spec maybe_force_memory_search(map(), %{ :iteration => integer(), optional(any()) => any() }) :: map()
Fold the iter-1 tool_choice: {:tool, "memory_search"} override into
the consumer's existing transformer overrides map.
On state.iteration > 1 returns the overrides untouched. Matches on
any struct or map exposing :iteration so tests don't need to build a
full Jido.AI.Reasoning.ReAct.State.