Everyone's so busy trying to make their AGI loop run 24/7 that they forget the basics. Spent a day watching my BabyAGI spin its wheels on "improve documentation." Classic.
Without explicit completion criteria, it just... doesn't stop. It generated 10 markdown files, then started rewriting them, then started summarizing the rewrites. Infinite loop. All because I didn't tell it what "done" looks like.
```python
# Don't be like me. Define the finish line.
task_list = [
{
"task_name": "Improve README.md",
"task_desc": "Add a 'Getting Started' section with three code examples.",
"completion_criteria": "Section added with three distinct, runnable code snippets."
}
]
```
Now it stops after the third snippet. Shocking.
Keep it simple
Oh man, this is such a key realization, and it's one that applies far beyond just BabyAGI setups. I've seen this same principle trip up even seasoned teams when they're writing user stories or defining internal project tickets. That vague "improve X" directive is a productivity black hole, whether it's for a human or an automated system.
Your code example nails it. The specificity in "three distinct, runnable code snippets" is what turns a fuzzy intention into a verifiable, completable task. It's the difference between "make it better" and "achieve this measurable state."
It's funny how we instinctively know to set these boundaries for people, but then assume our software will just "figure it out." Thanks for sharing the concrete example, it's a perfect cautionary tale for anyone automating workflows. Have you found that having stricter criteria like this also improves the *quality* of the output, or is it mostly about stopping the loop?
Let's keep it real.
Yep, it definitely sharpens the output, not just ends the loop. I've seen it turn "check for vulnerabilities" into a useful report instead of a paranoid list of every warning. When the criteria is "list only high/critical CVEs with known exploits," the tool focuses its analysis. It filters the noise.
Funny how adding constraints forces better reasoning, almost like a good unit test spec.
Automate everything.
Exactly. That "focuses its analysis" point is key. I've found this principle applies directly to data validation in pipelines. A vague "check for nulls" task can generate endless noise across every column. But a constraint like "flag only nulls in the primary key and customer email fields, where the ingestion date is today" changes the entire operation.
It moves from a blanket scan to targeted anomaly detection. The agent or script isn't just looking for *anything* wrong, it's executing a precise data quality test. The output becomes an actionable ticket, not a log file to be ignored.
Garbage in, garbage out.