GitHub user imbajin added a comment to the discussion: [Discussion] The selection of Agentic/Taskflow frame
> [@imbajin](https://github.com/imbajin?rgh-link-date=2025-02-28T20%3A47%3A30.000Z) > As per my understanding of 2, we need a way to integrate hugegraph agents > with any other existing framework. And we will provide an http api layer > abstraction or python SDK for hugegraph agents. For example. Someone working > on some projects involving AI agents. They thought that they needs to use > GRAPH RAG for some use case. Now for that, they will be able to import HG > agentic library say HG_agentic. Now using this library, they can create > agents using plane english (what the agent needs to do, given some input and > required output format.) Each agent will have the information about graph > from which information needs to be extracted. And it will have some inputs - > (output from previous agents, like node names , relationship names , > similarity search results, etc), the agent will convert txt2gql according to > the given prompt and graph structure knowledge. This way (Devs) can create > agents and orchestrat e them using our library HG_orchestrator by just passing all created agents in a data structure. > > HG_orchestrator will handle the order of agent execution. User can specify if > he want sequential in case next agent needs outputs from any previous agent , > parallel otherwise. > > If we need this, we need a framework having really good `WORKFLOW FEATURES`. > Because then we can be really flexible. (We can manage the flow of data > between agents, as specified by user, also we can add if-else validation > condition, deligation steps like deligate to previous agent with some > modified input.) > > Eg :- `HG_orchestrate([agent1, agent2, agent3], fllow="sequential", > data_flow: {agent1 : [agent2, agent3], agent2 : [agent3]}, deligation: > [{from:agent3, to:agent1 , condition :"some_condition", modification : > "required_modification"}]` > > One naive approach can be to do everything using simple python while loop, > here we don't need to manage different dependency conflicts. If (devs) use > AutoGen, and if we create HG_agentic SDK using crewai. Then there might be > dependency conflicts. > > If not, then we can follow the below priority order. > > Priority suggestion for workflow :- > > * 1. Llamaindex (have workflow features like checkpoint, trigger, retries, > streaming, context across runs, with really good example as per our needs) > * 2. pydantic AI > * 3. CrewFlow > * 4. Agno (don't have workflow features) @Aryankb Yes, I basically agree with your hypothesis and analysis. The best way for us to proceed is to provide an SDK for developers to better call, although that is not something that needs to be done immediately. And also as the https://github.com/apache/incubator-hugegraph-ai/issues/183#issuecomment-2692091406 mentioned We may try a more balanced option first. If we feel that the agent framework is heavy, we can directly reference/use their flow part instead of directly referencing the entire framework (after looking at the workflows of `Crewai` and `Llamaindex`, we can independently propose them) GitHub link: https://github.com/apache/incubator-hugegraph-ai/discussions/203#discussioncomment-12666615 ---- This is an automatically sent email for dev@hugegraph.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@hugegraph.apache.org
