Agents - Third party definition + remove dependence on naming convention

[planetf1]

When implementing #125 a naming convention was used to identify how to launch an agent, for example test.crewai_test.ColdWeatherCrew meant the file was in test/crewai_test.py, the class was ColdWeatherCrew. It must be in $PYTHONPATH.

The decision of whether an agent was bee/crewai/langchain was based on strings in the name. The code look for an appropriate @crew annotation to kickoff. This was done to avoid having to implement a new structure whilst developing.

The Agent class is currently defined in https://github.com/i-am-bee/bee-hive/blob/main/bee-hive/bee_hive/agent.py. Do we want to make this a BeeAgent instead?

For Bee agents we can create the agent dynamically. I think for third party agents we would see this out of scope. This means that whilst with bee we might specify descriptions, model etc, with the others we can't, yet we also need to know where the code is, and perhaps some other information.

We also need to think about the yaml to represent the differences & specifically

• where is the file/module/class we need?
• what method do we need to call? Or an API call?

I think this can be implemented in a future iteration.

[psschwei]

My gut instinct is that kind should stay the generic Agent and that we should specify BeeAgent, CrewAgent, etc. in the spec (maybe .spec.type ?) though I don't have a strong opinion here just yet.

cc @maximilien

[planetf1]

@maximilien Given the existing PR needs refactoring to align with the creation of the Agent class, can we add a type field as above in the agent definition.

I don't think we have an agent spec yet?

In the original workflow.yaml we had

    agents:
      - name: current-affairs
      - name: hot-or-not

which would logically extend to:

    agents:
      - name: current-affairs
         type: bee
      - name: hot-or-not
         type: crewai

The valid types could be bee, crewai at a minimum. (Optionally add langchain)

With the current spec we can't so easily slot this in... will look/discuss

[psschwei]

We do have an agent spec, here's an example (I don't think we init all fields in the class though): https://github.com/i-am-bee/bee-hive/blob/main/examples/bee-hive/weather-checker/agents.yaml

Another thought I had on this earlier: would a type: code make sense here too? Not sure if that would simplify things or not. And in any case, not necessarily something we need right now, just a thought.

[planetf1]

I added a 'framework' attribute in #148 . It assumes 'bee' if not set.

There are more attributes needed, and more thoughts about how we deal with different kinds of agents - local, remote bee/3rd party. They will require different properties. Ideally our specs will also ensure we capture mandatory parms of each.

I'd err on getting changes merged quickly, and then redoing - for example if we think 'framework' is a bad term and it should be expressed differently.

I switched from 'type' as it's a very overused term.

[maximilien]

I think we need to be able to specify the agent code with:

1. code (in place)

2. GitHub link

3. an image

Each approach has its use. Option 1 is quick and dirty for local tests and devs. Option 2 is for real dev and test since allows all the benefits GH brings. And option 3 is for production and code releases.

And best part is should be no change to schema. Just read the code section value and decide based on its value.

:)

[psschwei]

Agree with all 3 ^^^
Buildpacks (https://buildpacks.io) might make sense here
FYI @akihikokuroda