Design choice: Custom tooling vs. `gollm`'s built-in `tools`

[yisrael-rosen]

Generated by Gemini experimental 1206 🤖

The Enzu framework utilizes a custom tooling mechanism that currently uses JSON for representing function calls and parameters, despite gollm's native support for tool handling via its integrated tools functionality.

What is the rationale behind developing a separate system within Enzu? What specific advantages or capabilities does the custom implementation offer that are not achievable with gollm's built-in tools?

Were there any technical limitations or performance considerations that influenced this design choice? Was the potential for code simplification and enhanced gollm integration through the use of its native tools mechanism evaluated?

It's worth noting that Enzu's current implementation uses JSON, while gollm's approach, especially when interacting with Anthropic's API, appears to be more aligned with Anthropic's recommendations by utilizing XML for function calling. This potentially allows for more accurate and reliable communication with the API. Adopting gollm's built-in tools mechanism might improve compatibility and accuracy, particularly when using Anthropic models.

Understanding the motivations behind this architectural decision would greatly aid in comprehending the overall design philosophy of Enzu.

[teilomillet]

I realize now that I made a naming choice in gollm that's causing some confusion. Let me explain the difference: In gollm, which is our base library for LLM interactions in Go, we have what we call 'tools' - these are high-level utility functions like ChainOfThought() that help developers work with LLMs more effectively. However, in enzu, which is built on top of gollm, we're using the correct term 'tools' differently - we're using it to mean function-calling capabilities, similar to how GPT uses tools for specific operations like web searches or calculations.
To make this clearer and align with another improvement request I've received, I'm considering moving enzu's function-calling tools directly into gollm. This would consolidate all our tool-related functionality in one place, making the codebase more organized and easier to understand.