```                   # 📋 Session Report
    λλ              
   λ⊙λ⊙             
  λλλλλλ            
 λλλλλλλλ           
    λλ              
    λλ              
    λλ              
    λλ              
    λλ              
    λλ              
    λλ              
    λλ              
```                 

**🔑 Session ID:** e83c57a5-2efc-4b74-af87-b09b817f0127

---

## 📊 Statistics

### Turn Counts

| Metric | Value |
|--------|-------|
| Total Turns | 72 |
| 👤 User Turns | 36 |
| 🤖 LLM Turns | 36 |

### 🔧 Tool Calls

**Total Tool Calls:** 44

`bash_read-file      `   15 ████████████████████████████████████████████████████████████

`sqlite_knowledge_store_query`   14 ████████████████████████████████████████████████████████

`bash_grep-files     `   13 ████████████████████████████████████████████████████

`bash_list-files     `    1 ████

`bash_write-file     `    1 ████


### 💾 Byte Usage

`Input     `    522 KiB ████████████████████████████████████████████████████████████

`Output    `      2 KiB 

`Reasoning `      6 KiB 
**Total:** 531 KiB

---

## 👤 Step 1: User Turn

### 📝 System Prompt

```
You are an expert technical documentation writer specializing in Haskell codebases.

=== CRITICAL: ALWAYS READ THIS FIRST ===
Before doing ANY work on this codebase:
1. IMMEDIATELY read docs/AI-CONTEXT.md for essential context
2. Query the knowledge base: SELECT * FROM project_overview
3. Check existing docs: SELECT doc_path, title FROM docs_index
4. Review what's documented: SELECT module_name, documented_in FROM code_index

=== PROJECT: AGENTS FRAMEWORK ===
This is a Haskell framework for AI agent orchestration with:
- Multi-agent hierarchies (agents call other agents as tools)
- Tool system: bash scripts, MCP servers, OpenAPI specs, IO tools
- Session persistence for conversations
- TUI (Terminal UI) + CLI + MCP server interfaces
- OpenAI-compatible LLM integration

=== KEY ARCHITECTURE ===
- AgentTree: Manages multi-agent discovery, cycle detection, reference validation
- Runtime: Executes agent conversations, manages tool registration
- Base types: Agent, AgentId, ConversationId, ExtraAgentRef (in System.Agents.Base)
- 79 Haskell modules in System.Agents namespace

=== DOCUMENTATION STRUCTURE ===
docs/AI-CONTEXT.md          - READ THIS FIRST (orientation)
docs/README.md              - Project overview
docs/architecture.md        - System design, runtime, agent tree
docs/tools.md               - Tool registration (bash/MCP/OpenAPI/IO)
docs/mcp.md                 - Model Context Protocol
docs/sessions.md            - Session management
docs/tui.md                 - Terminal UI (Brick library)
docs/cli-commands.md        - CLI reference
docs/export-import.md       - Tool sharing
docs/file-loader.md         - File loading utilities
docs/ITERATIVE-WORKFLOW.md  - Multi-step documentation patterns
docs/ai-assistant-guidelines.md - Detailed reference

=== KNOWLEDGE BASE ===
SQLite database tracks state in tables:
- project_overview: Project metadata
- code_index: 79 modules with documentation linkage
- docs_index: Documentation files registry
- commits_seen: Git commits processed

=== DOCUMENTATION STANDARDS ===
- Use Markdown format
- Include ASCII diagrams (Graphviz for complex)
- Provide Haskell type definitions
- Add code examples
- Cross-reference related modules

=== WORKFLOW ===
1. Query knowledge base for current state
2. Identify documentation gaps
3. Read relevant source code
4. Create/update documentation
5. Update knowledge base tables
6. First line of response MUST be a summary

=== MODULE-TO-DOC MAPPING ===
System.Agents.Base          -> docs/architecture.md
System.Agents.Runtime*      -> docs/architecture.md
System.Agents.AgentTree*    -> docs/architecture.md
System.Agents.Tools.*       -> docs/tools.md
System.Agents.MCP.*         -> docs/mcp.md
System.Agents.Session*      -> docs/sessions.md
System.Agents.TUI.*         -> docs/tui.md
System.Agents.CLI.*         -> docs/cli-commands.md
app/Main.hs                 -> docs/cli-commands.md
System.Agents.ExportImport* -> docs/export-import.md
System.Agents.FileLoader*   -> docs/file-loader.md

=== CRITICAL TYPES ===
Agent: Core configuration (slug, apiKeyId, modelUrl, systemPrompt, toolDirectory)
AgentId/ConversationId/SessionId: UUID-based identifiers
ExtraAgentRef: Cross-agent reference for agent hierarchies
ToolRegistration: Tool exposed to LLM (name, description, parameters, executor)
ToolExecutionContext: Tracks recursion depth, call stack

=== TRACING PATTERN ===
All operations use Prod.Tracer:
  myFunction :: Tracer IO MyTrace -> IO ()
  myFunction tracer = do
    runTracer tracer Started
    result <- operation
    runTracer tracer (Completed result)

=== ITERATIVE WORK ===
For multi-step tasks:
- Chunk by subsystem or document
- Update KB after EACH chunk
- Include handoff notes for next invocation
- Run consistency checks between steps

=== REMEMBER ===
- First line of EVERY response must be a summary
- Always update knowledge base before finishing
- Query state first, don't assume
- Cross-reference related documentation
- Test code examples mentally
```

### 💬 User Query

# Update docs

Please update the docs.

In particular mention the support for Recursive Language Models, configurable with the LUA builtin toolbox like the following

```json
{
  "tag": "OpenAIAgentDescription",
  "contents": {
    "slug": "local_lrmlua",
    "flavor": "KimiV1",
    "modelUrl": "https://api.moonshot.ai/v1",
    "apiKeyId": "kimi",
    "modelName": "kimi-k2.5",
    "announce": "The main agent, capable of reasoning.",
    "systemPrompt": [
      "You are a helpful software agent trying to solve user requests"
    ],
    "extraAgents": [
      {
        "slug": "local_lrmlua",
        "path": "kimi-10.lrmlua.json"
      }
    ],
    "bashToolboxes": [
      {
        "tag": "SingleTool",
        "contents": "./tools/askuser/ask-user.bash"
      }
    ],
    "builtinToolboxes": [
      {
        "tag": "LuaToolbox",
        "contents": {
          "Name": "lua",
          "Description": "Sandboxed Lua interpreter",
          "MaxMemoryMB": 256,
          "MaxExecutionTimeSeconds": 300,
          "AllowedTools": [
            "bash_ask_user",
            "io_prompt_agent_local_lrmlua",
            "sqlite_shared_working_memory_query"
          ],
          "AllowedPaths": [
            "./repro-cases",
            "./README.md"
          ],
          "AllowedHosts": [
            "localhost",
            "127.0.0.1"
          ]
        }
      },
      {
        "tag": "SqliteToolbox",
        "contents": {
          "Name": "shared_working_memory",
          "Description": "A base to help you coordinate large works.",
          "Path": "./dev-memory.db",
          "Access": "read-write"
        }
      }
    ]
  }
}

```

---
From #413



### 🛠️ Available Tools

- **bash_grep-files** (`bash_grep-files`)
  - Description: Search for a pattern in files using 'git grep'
- **bash_read-file** (`bash_read-file`)
  - Description: Read the contents of a file
- **bash_check-code** (`bash_check-code`)
  - Description: Check Haskell code by compiling or testing
- **bash_list-files** (`bash_list-files`)
  - Description: List all files in the project
- **bash_get_git_log** (`bash_get_git_log`)
  - Description: read a online log of the git history
- **bash_get_git_commit** (`bash_get_git_commit`)
  - Description: read a git commit by it's short name or long sha
- **bash_generage_graphviz** (`bash_generage_graphviz`)
  - Description: generate a graphviz image from a dot script, the resulting png is stored under '<path>[.png]'
- **bash_write-file** (`bash_write-file`)
  - Description: Write content to a file
- **sqlite_knowledge_store_query** (`sqlite_knowledge_store_query`)
  - Description: A knowledge base about the code base and how it works.

---

## 🤖 Step 2: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

The user wants me to update the documentation to mention support for Recursive Language Models (LRM) with a Lua builtin toolbox configuration example. Let me first:

1. Read the AI-CONTEXT.md file for essential context
2. Query the knowledge base for current state
3. Check existing documentation files
4. Read relevant source code to understand the Lua toolbox implementation
5. Update the appropriate documentation

Let me start by reading the context and querying the knowledge base.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_read-file**

- **sqlite_knowledge_store_query**

- **sqlite_knowledge_store_query**

---

## 👤 Step 3: User Turn



---

## 🤖 Step 4: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Good, I've got the context. Now I need to:
1. Read the tools.md file since this is about Lua toolbox configuration
2. Read the relevant source code for Lua toolbox to understand the implementation
3. Update the documentation

Let me first read the tools.md file and search for relevant source code about Lua toolbox and Recursive Language Models.
</details>

### 💬 Response

Now let me read the tools documentation and find relevant source code about Lua toolbox and Recursive Language Models:

### 🔧 Tool Calls

- **bash_read-file**

- **bash_grep-files**

- **bash_grep-files**

---

## 👤 Step 5: User Turn



---

## 🤖 Step 6: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me search for more specific patterns related to the Lua toolbox configuration and Recursive Language Models. I need to find the source code that handles this.
</details>

### 💬 Response

Let me search for more specific patterns and read the relevant source files:

### 🔧 Tool Calls

- **bash_grep-files**

- **bash_grep-files**

- **bash_read-file**

---

## 👤 Step 7: User Turn



---

## 🤖 Step 8: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now I need to find the LuaToolboxDescription type and understand how it's used. Let me also look at how extra agents work and where the io_prompt_agent pattern comes from.
</details>

### 💬 Response

Now let me search for the LuaToolboxDescription type and how extraAgents work:

### 🔧 Tool Calls

- **bash_read-file**

- **bash_grep-files**

---

## 👤 Step 9: User Turn



---

## 🤖 Step 10: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

I now have a good understanding of:
1. `LuaToolboxDescription` with its fields like `luaToolboxAllowedTools`, `luaToolboxAllowedPaths`, `luaToolboxAllowedHosts`
2. `ExtraAgentRef` for self-referencing agents (supporting recursive agents)
3. How agents can reference themselves for recursive language model capabilities

The user's example shows:
- An agent that references itself via `extraAgents`
- A Lua toolbox configured with `AllowedTools` including `io_prompt_agent_local_lrmlua` (which would be the auto-generated tool name for the agent to call itself)
- The pattern enables Recursive Language Models (LRM)

Now I need to update `docs/tools.md` to document this capability. I should add a section about Recursive Language Models with the Lua toolbox.
</details>

### 💬 Response

Now let me check how the io_prompt_agent tool is generated by looking at the IO tools implementation:

### 🔧 Tool Calls

- **bash_grep-files**

---

## 👤 Step 11: User Turn



---

## 🤖 Step 12: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me search more broadly for the IO tool generation and agent self-reference.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_grep-files**

- **bash_read-file**

---

## 👤 Step 13: User Turn



---

## 🤖 Step 14: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me search for where agents are converted to IO tools - this is the mechanism that allows recursive agent calls.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_grep-files**

- **bash_read-file**

---

## 👤 Step 15: User Turn



---

## 🤖 Step 16: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me search for how extra agents are loaded and turned into IO tools. This is what creates the recursive capability.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_grep-files**

---

## 👤 Step 17: User Turn



---

## 🤖 Step 18: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me try a different approach and look at the Runtime module to understand how agents become tools.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_read-file**

---

## 👤 Step 19: User Turn



---

## 🤖 Step 20: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

The old runtime has been removed. Let me look at the AgentTree module which handles the agent hierarchy and extra agents.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_read-file**

---

## 👤 Step 21: User Turn



---

## 🤖 Step 22: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now I have a good understanding of the system. Let me look at how the agent tool naming works - specifically how `io_prompt_agent_{slug}` is generated.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_grep-files**

---

## 👤 Step 23: User Turn



---

## 🤖 Step 24: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me search for how agent tools are named, maybe it's in the ToolRegistration module.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_grep-files**

---

## 👤 Step 25: User Turn



---

## 🤖 Step 26: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me look at the OS Agents module which handles the agent-to-tool conversion.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_read-file**

---

## 👤 Step 27: User Turn



---

## 🤖 Step 28: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me look at the conversation orchestration module to find where agent tools are created.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_grep-files**

---

## 👤 Step 29: User Turn



---

## 🤖 Step 30: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me search more broadly.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_list-files**

---

## 👤 Step 31: User Turn



---

## 🤖 Step 32: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me look at the OneShot module to see how agent tools are created. The `io_prompt_agent` tool naming is likely there.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_read-file**

---

## 👤 Step 33: User Turn



---

## 🤖 Step 34: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

I see how the agent tree and tool loading works, but I need to find where the "io_prompt_agent" naming comes from. Let me check the ToolLoader module.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_read-file**

---

## 👤 Step 35: User Turn



---

## 🤖 Step 36: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now I have a good understanding of how the system works. Now let me look at how agent-to-agent tools are registered. Let me look at the ToolRegistration module to see how agents become tools.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_read-file**

---

## 👤 Step 37: User Turn



---

## 🤖 Step 38: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now I have a complete understanding of the system. Let me now understand the naming convention for agent tools. Looking back at the `AgentTree` module, I see the `agentToTool` function in `Props`:

```haskell
data Props = Props
    { ...
    , agentToTool :: OSAgentNode -> AgentSlug -> AgentId -> ToolRegistration
    -- ^ Function to create a tool registration from an agent node
    }
```

This is passed in from the caller. Let me find where this is actually defined to understand the naming pattern for agent tools (like `io_prompt_agent_{slug}`).
</details>

### 💬 Response

Let me check where `agentToTool` is defined:

### 🔧 Tool Calls

- **bash_grep-files**

---

## 👤 Step 39: User Turn



---

## 🤖 Step 40: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me search more broadly to find where agent tools are created.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_read-file**

---

## 👤 Step 41: User Turn



---

## 🤖 Step 42: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now I understand the structure better. Let me look at the OneShotCmd module to see how `agentToTool` is defined.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_read-file**

---

## 👤 Step 43: User Turn



---

## 🤖 Step 44: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now I see that `OneShotTool.turnAgentRuntimeIntoIOTool` is where the agent tool is created. Let me look at that module.
</details>

### 💬 Response



### 🔧 Tool Calls

- **bash_read-file**

---

## 👤 Step 45: User Turn



---

## 🤖 Step 46: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now I have a complete understanding of the system. The key points are:

1. The tool name for an agent is generated as `"prompt_agent_" <> Base.slug agent` (line 67-68 of OneShotTool.hs)
2. When an agent references itself via `extraAgents`, it creates a tool that can call itself
3. This enables Recursive Language Models (LRM) - agents that can call themselves recursively
4. The Lua toolbox can be configured with `AllowedTools` to include `io_prompt_agent_{slug}` to allow the Lua script to call the agent itself

Now I need to update `docs/tools.md` to add documentation about:
1. Recursive Language Models (LRM) support
2. The Lua toolbox configuration for enabling self-referential agents
3. An example configuration showing how to set this up

Let me update the documentation now.
</details>

### 💬 Response

Now I have a complete understanding. Let me update the `docs/tools.md` file to add documentation about Recursive Language Models with the Lua toolbox:

### 🔧 Tool Calls

- **bash_write-file**

---

## 👤 Step 47: User Turn



---

## 🤖 Step 48: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now I need to update the knowledge base to reflect the documentation changes. Let me query the current state and update the docs_index if needed.
</details>

### 💬 Response

Now let me update the knowledge base to reflect these documentation changes:

### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 49: User Turn



---

## 🤖 Step 50: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

The knowledge base doesn't have a description column. Let me check the schema and update appropriately.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 51: User Turn



---

## 🤖 Step 52: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

The docs_index already has the updated description with LRM mentioned. The update I tried may have worked. Let me also check if there's a need to update the code_index to ensure the Lua toolbox modules are linked properly.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 53: User Turn



---

## 🤖 Step 54: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

The Lua modules need to be updated to link to the tools.md documentation. Let me update the code_index.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 55: User Turn



---

## 🤖 Step 56: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Interesting - the LuaToolbox modules aren't in the code_index yet. Let me add them.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 57: User Turn



---

## 🤖 Step 58: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now let me update the OS Lua resources module to reference tools.md as well.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 59: User Turn



---

## 🤖 Step 60: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now let me verify the changes are in place and then update the project_overview to track the last documentation update.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 61: User Turn



---

## 🤖 Step 62: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Great! The tools documentation is now linked to 36 modules. Let me verify the LuaToolbox modules were added correctly.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 63: User Turn



---

## 🤖 Step 64: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

All the Lua toolbox modules are now indexed. Let me update the project_overview to reflect the last documentation update.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 65: User Turn



---

## 🤖 Step 66: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Now let me verify the changes and provide a summary.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 67: User Turn



---

## 🤖 Step 68: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

The project_overview doesn't have a last_doc_update key yet. Let me add it.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 69: User Turn



---

## 🤖 Step 70: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Let me verify everything is in order.
</details>

### 💬 Response



### 🔧 Tool Calls

- **sqlite_knowledge_store_query**

---

## 👤 Step 71: User Turn



---

## 🤖 Step 72: LLM Turn

### 💭 Thinking Process

<details>
<summary>Click to expand reasoning</summary>

Everything is now updated. Let me provide a summary of the changes.
</details>

### 💬 Response

**Summary:** I've successfully updated the documentation to include support for Recursive Language Models (LRM) with the Lua builtin toolbox.

## Changes Made

### 1. Updated `docs/tools.md`
Added a new section **"Recursive Language Models (LRM) with Lua"** that documents:

- **Concept**: How agents can reference themselves via `extraAgents` to enable recursive self-calling
- **Configuration**: Complete JSON example showing:
  - Self-referential `extraAgents` configuration
  - `LuaToolbox` with `allowedTools` including `io_prompt_agent_{slug}`
  - Security settings (`maxMemoryMB`, `maxExecutionTimeSeconds`)
  - Access controls (`allowedPaths`, `allowedHosts`)
  - Integration with other toolboxes (SQLite for shared working memory)

- **Security Features**: Documented sandboxing, memory limits, timeouts, path/host whitelisting
- **Standard Library Modules**: Listed available Lua modules (json, http, time, fs, text, tools)
- **Example Lua Script**: Shows how to use `tools.call()` to invoke the recursive agent
- **Tool Naming**: Documented `lua_{name}_execute` naming pattern
- **Error Handling**: Listed possible Lua script error types

### 2. Updated Knowledge Base
- Added 8 Lua toolbox modules to `code_index`:
  - `System.Agents.Tools.LuaToolbox`
  - `System.Agents.Tools.LuaToolbox.Modules.*` (Json, Http, Time, Text, Fs, Tools)
  - `System.Agents.Tools.LuaToolbox.Utils`
- Updated `System.Agents.OS.Resources.Lua` to reference `docs/tools.md`
- Added `last_doc_update` timestamp to `project_overview`

### Key Features Documented

The Lua toolbox enables agents to:
1. **Execute sandboxed Lua scripts** for tool orchestration
2. **Call themselves recursively** via the `io_prompt_agent_{slug}` tool when self-referenced in `extraAgents`
3. **Access a secure subset** of filesystem, HTTP, and other tools through configurable whitelists
4. **Maintain shared state** through SQLite or other persistent toolboxes
5. **Perform complex multi-step reasoning** by delegating sub-tasks to themselves
