Minimum Viable Agent (MVA) - Refinement

[OWigginsHay]

Title

In addition to my post #89.
And to aid: #116
I will now refine what the MVA (Unit) is and how it operates, as well as an abstract set of representations which will allow us to build abstraction to create similar agents with varying functionality. My hope is that this can also inform project structure and design decision for processes such as:

• Tool Chaining
• Assistant Creation

Context for a Unit

A bit of summary from: #89.

Interface

The bit that user interacts with. This talks in natural language, it can converse, it is also the only assistant type which has function tools. It therefore gets to decide when to invoke them. This combination means that the interface is the conversational front that interprets language and can turn requests for tools into request_function commands. This is an Interface Agent with an Interface Thread for persistent context.

Functional

Here when the Interface Run makes a request for a new function, the structure is sent to a Functional Thread where a Functional assistant is tasked with turning the schema into an actual python function, which is then stored. This is the externally interacting part, now when the Interface Assistant calls tool, the call is directed to perform a module import from the python store where the python code is read and executed and the result returned to the Interface Thread.

Slide Pack

The distinction above is useful as we do not want complexity where it is hard to track, the more capabilities an agent has, the more opportunity it has to go on loops and cost a lot of money and also perform unneeded tasks that are outside of it's specialty. Capabilities such as retrieval, code_interpreter and functions. If we keep the conversational part as the one with the power to do more, but have basic assistants which serve them, we also reduce the risk of cascade instantiation, where a function_tool assistant keeps making assistants similar to itself and it never ends. If we impose that a functional_tool assistant can only ever have a basic assistant as a servant, the servant can't create more, it's just has to try it's best to perform tasks.

The core point here is that in the PRs and util functionality, we can't just have a single method or class to determine what a chat or thread run looks like... it's much more complicated, different assistant will need different thread run capabilities, especially if we want to insert our own pre defined functions in the loop to be used like an API.

The FucntionalAssistant with it's thread branching off of the Interface call to submit_tools is an Extension! We can make more, it also enforces the idea that Agents can create an Extension if they need, but there is not a way for an extension to make more agents or extension.

Where is the data store? At the moment the agent makes it in the tool_maker directory, but each agent should probably have it's own space we can monitor... how do we stop one agent navigating the file structure and deleting another agents python functions? In fact how do we limit scope and the ability for agents to interact with it's own codebase.

[marktellez]

A note on "how to keep agents from deleting code that isnt theirs"

I have had a lot of success by making agents fetch and rebase (the same way I do) before they push code. since the agents are doing this constantly, they don't end up stepping on each other, and they can "see" code submitted by other agents. I don't use PRs yet with agents, but long term, that would be included in this scheme.

Also, none of my agents are "general" developer agents. Agents are "spun up" and "down" for specific tasks, so they don't go out of scope. They are responsible for adding 1 addition, think TDD.

I find that agent one shot conversations almost always get a better response than letting agents build up a lot of context.

[OWigginsHay]

Curious, is the PR and rebase language because you are working on agents in a github repo?

[OWigginsHay]

These agents would also be "Spun up" and "Spun down" but it's true that with my agents I see the opposite where the longer the context the better the performance, I imagine that is because mine has an inbuilt feedback loop though. The context persistence in the form of having the assistant instruction update periodically based on pooled data is an idea I am keen to test though