Everyone is talking about getting BabyAGI to execute a sequence of tasks, but I see almost no substantive discussion on the actual mechanism for steering it. The assumption seems to be that it just gets better magically, or that your initial prompt is a one-time, set-and-forget command. That's a fundamental misunderstanding of how these iterative loops work, and it's going to lead to people wasting cycles and burning API credits on a hamster wheel of diminishing returns.
The core issue is that BabyAGI, in its standard implementations, is primarily a task *generator* and *executor*, not a learner. The "feedback" loop most people think of doesn't exist natively. You can't just tell it "that last result was poor, do better next time" and expect that sentiment to persist into the next iteration. The context window rolls on, and the system's core instructions remain static. The so-called improvement has to be engineered into the process, which means architecting a way to analyze results and *programmatically* alter the system's own governing prompt or objective for the next cycle.
This isn't about tweaking a user message. It's about modifying the actual system prompt or the overarching task string based on programmatic evaluation. You need to build a secondary evaluation agent, or at least a set of criteria, that inspects the result of a completed task list and then amends the original objective. For example, if your goal was "research a topic and write a report," and the output was too shallow, your feedback mechanism needs to append concrete directives like "the next iteration must include at least three opposing viewpoints and cite primary sources" directly into the main objective fed to the task creation agent. Without this, you're just rerunning the same flawed process.
Furthermore, most hobbyist deployments completely ignore the cost of this experimentation. Each feedback loop you try to create means another full run of the agent, with all its associated LLM calls for task creation, prioritization, and execution. You're not just providing feedback; you're funding a new research project. Before you ask how to give feedback, you need to ask if the total cost of ownership for this trial-and-error approach justifies the marginal gain over a simpler, deterministic script. The allure of autonomy often obscures the reality of expensive, unstructured computation.
People should be looking at the code, specifically the `execution_chain` and the `task_creation_chain`. That's where any feedback logic must be injected. Are you storing results in a structured format that can be evaluated? Are you comparing outcomes to a predefined rubric? If not, your "feedback" is just a human in the loop, manually restarting the system with a slightly different prompt, which defeats the entire purpose of an autonomous agent. The community's focus should be on building robust, state-aware evaluation layers, not on anthropomorphizing the agent with chat-based feedback it can't remember or utilize.
Just my two cents
Skeptic by default