agent: definition

[psschwei]

As a user, I want to be able to define an agent in YAML and have it be created in my bee-hive.

Behind the scenes, we should be able to translate the YAML to make a call to the Bee API to create the agent.

[akihikokuroda]

These are the list of arguments that the beta.assistants.create method in bee-api.

tools 
tool_resources
name
description
instructions
system_prompt_overwrite
metadata
top_p
temperature

The response_format in OpenAI API is not supported for the output format.
The input format can be concatenated to the instructions

[planetf1]

When creating an agent in bee

• The inference provider is specified by LLM_BACKEND. I'm not sure if a single bee instance can work with >1 backend concurrently. This is predominantly related to runtime configuration
• The model used, if not specified, is the default for the inference provider. However it can be specified programatically. This is closely related to the prompt (instructions) . This is specified on the api call to create an assistant

[akihikokuroda]

The bee-api seems to handle concurrency. The inference providers seem to support concurrency, too.

[planetf1]

I should have clarified. I meant working with multiple inference providers concurrently - for example both ollama & watsonx (as opposed to multiple concurrent requests to a single provider)

[psschwei]

I lean towards each agent interacting with just 1 LLM/backend... for additional LLMs/backends I think the happy path is just deploy another agent with the additional backend/LLM

[matiasmolinas]

Hi everyone, I’d love to pick up Issue #47 regarding the agent definition. My goal is to let the Hive instantiate either a Bee-Framework-based agent or a smolagent-based agent from the same definition/config—so developers can pick which framework they prefer without writing separate code for each.

Proposed Approach

Agent Type Field: Introduce a field in the Hive config (e.g., type: "bee" or "smolagent") that indicates which framework to use when instantiating the agent.
Unified Instantiation: In the Hive code, if the user sets type: "bee", we instantiate a BeeAgent from the bee-framework; if type: "smolagent", we spin up a corresponding smolagent instance.
Single LLM Paradigm: Each agent is still tied to just one LLM/backend at a time. If a user wants multiple LLMs, they’d deploy multiple agents, each with its own type and model config.
Future Extensions: Later on, we might add advanced logic like agent collaboration or multiple backends, but for now, this issue aims to keep it simple: a single, well-defined agent connected to exactly one framework and LLM.
If that sounds good, I’ll start drafting a PR to implement this. Let me know if you have questions or additional ideas—would love to hear your feedback!

Looking forward to collaborating on this.

[psschwei]

Hey @matiasmolinas that's a great idea (and something we've been thinking about too).

Would you mind creating a separate issue for it? Would be happy for you to get started working on it.

[matiasmolinas]

Hey @psschwei , thanks for the prompt feedback! Sure, I’ll create a new issue dedicated to letting Hive instantiate either Bee-Framework-based agents or smolagent-based agents from the same YAML definition. This way, we don’t clutter up this thread with a separate feature discussion. I’ll link the new issue once I open it.

Looking forward to collaborating!

[matiasmolinas]

Hey everyone, just a quick update: I’ve created Issue #99 to handle the idea of letting Hive instantiate either a Bee-based or smolagent-based agent from a single YAML definition. This way, we keep this thread focused on the core agent definition goals, while #99 covers the multi-framework instantiation approach.

Thanks again for the feedback, and let me know if you have any thoughts on the new issue!

[planetf1]

In addition to the yaml definitions for Agent, Workflow, we may need one for AgentExecutor or similar (something that can execute a bee agent, or perhaps a smolagent)

For bee this might be addressed by host/port. We might have other hints around it's capabilities, priority, scaling, version. Workflows might need to declare constraints on these