Tool Creation

Introduction

It has become apparent to me that the task of tool creation runs much deeper than the surface level analysis. I believe the Tool Creation challenge deserves it's own milestones and roadmap. Despite organisation of communication currently being assessed the number 1 technical challenge, tools will be an integral part of that challenge. This is because the method utilised so far for on demand tool creation is via the same proccess that would be used for external API calling, and when it comes to agents performing directed communication, I believe we will likely use some kind of API calling mechanism to initiate that payload.

Here is a list of points I think need refinement:

• Message History & Thread Priming
• Different Thread Metatypes
• Different Assistant Metatypes
• Request Schemas
• Namespaces
• Access Scopes
• Rate Limits
• Function Moderation

Pre Requisite - Minimum Viable Agent (MVA)

TLDR on Units

• The MVA as declared in code has now been named a Unit.
• A Unit has one function called chat which allows the user to provide CMD input to the Unit.
• A Unit has an InterfaceAssistant and a FunctionalAssistant, each with a corresponding Thread.
• The InterfaceAssistant has function calling enabled and can request new functions which will be written by the FunctionalAssistant.

Message History

Given that a thread is basically a vehicle for passing a conversation history to an Assistant for it to provide a response. There is no reason we could not have pre-defined "Synthetic Conversation" ready to populate threads with for the purpose of priming an Assistant. The idea here is that when a new Assistant is spawned, it knows nothing about what it is outside of it's Instruction/Mission and it's attached files. This is great already but during my testing I have encountered many kinds of responses from Assistants and tools that are clearly nuanced and need a different approach to provide full context to the Assistant.

Examples

Assuming we have an agent which can create it's own tool, which I have already made and is in the codebase. These kinds of responses can be seen:

• "Sorry, as an LLM, I can't make a function which ... Here is a hypothetical explanation of how you might ..."
• "I only have one function, "request_function", I have no function to run commands using CMD." Normally these are quick to resolve, you simply tell the agent that it communicates with a wider system that enables it to interact with the outside world and it can create these functions, it just has to describe them in the 'request_function'. For the second, reminding the agent it can use the 'request_function' to make functions it needs to perform tasks whenever it requires suffices to begin compliant behaviour.

Assistants are also usually bad at describing functions in their requests to begin, or more specifically the Functional Assistant might not include the python keyword return in a function it writes if the uses directs the Unit to "print" something. This will lead to the Interface Assistant believing it is interacting with a broken or outdated API as it sees no response when running a newly made function.

TO_BE_WRITTEN

1. Different Thread Run Operations
2. Tool Routing (Sys, Local)
3. Request Schema
4. Namespaces
5. Access Scopes
6. Rate Limits $$
7. Function Moderation