# `JidoGralkor.ReAct`
[🔗](https://github.com/elimydlarz/jido_gralkor/blob/main/lib/jido_gralkor/re_act.ex#L1)

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.

# `maybe_force_memory_search`

```elixir
@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`.

---

*Consult [api-reference.md](api-reference.md) for complete listing*