As you can see:
  * The LLM can auto-adjust depending on what the REPL output is. In its second try, it already has access to the original 52-count `FRUIT_NAMES` variable, so it was able to reuse that variable to slice it into a `FRUIT_NAMES_50` variable!
  * If the assert statement fails, the LLM will receive a REPL error and work to fix the code!
  * The LLM does not need to READ the dictionary `fruit_r_count` at all! It can just straight away pass it back to the user.
  * **The FINAL(.) just returns the result of an expression straight from the REPL back to the output of the scaffold!**


> **This is the first time that we have discussed a path where an agent is able to return an output to the user without** (a) reading the whole dictionary into the context (b) generating the dictionary token-by-token (c) not use file systems at all _(in theory CodeAct could have written the dictionary in a file system and asked the user to read from there)_
For this reason, RLM outputs are not bound by the context length of the LLM. They can return arbitrarily long outputs, as large as the Python variable can hold.
### 3.3 Recursive Subagents
**We have talked about some cool parts of RLMs already, but we haven't even gotten to the recursive parts.**
In RLMs, the recursive-ness is similar to subagents, but there are fundamental differences in how information gets shared between subagents that are different in RLMs.
  * RLMs have access to a special function inside their REPL called `llm_query`
  * `llm_query` inputs a single string.
  * `llm_query` invokes a brand new REPL environment, completely fresh, and sets context = whatever the parent LM had passed into `llm_query`
  * This child RLM must solve the problem and send it back using FINAL
  * The child RLM output is not loaded automatically into the parent RLM's context. Instead, it is just another expression inside the Python REPL!


To understand all this, let's take Problem 2from above.
markdown