Greg Roodt

Feels like everyone making their own agent stumbles across the same primitives and thinks they solved something Let me save you some time (read this, it's funny and useful): - You're going to make an agent - You're going to run it on benchmarks > It's going to suck - You're going to make a tool to analyze traces - You're going to say this helped you > It wont work - You're going to think about role based agents for solving a single task - You're going to make a workflow for solving a benchmark > Both will work. Neither are generalized - You'll think you made it > It will be nearly unusable by an end user > Back to square one - You're going to realize you're stuck with a for loop - You're going to think about swarms > In swarms single agent usability doesn't matter - But wait you need a task manager - But wait you need a merge queue - But wait you need compression for long jobs > Compression is a foot gun - But wait now you need an agent to manage it all - But wait now you need something that checks to make sure the manager is managing - You're going to go back to single loop agents - Well, subagents seem like the way to do all of this > Bam! Plot twist: subagents are hard to do well - You're going to think "Hmm well subagents isolate context" because <Insert_Person> said so - You're going to start to look at other agent implementations > How have they all solved compaction, multi-agent, task management, memory etc.? - You're going to realize it's all just tradeoffs, but most of them have only one side people care about - "Oh it's all just context engineering" > Yep. But it has to be good and it has to be general. > Back to the starting loop. Rinse and repeat. Congrats. Keep it simple. Keep it general.