Can be better to have a different repo for examples?
Btw great project! Kudos
This example might be close to what you're describing: https://github.com/agno-agi/agno/blob/main/cookbook/workflow...
It chains agents for web research, content extraction, and writing with citations.
I used it as a starting point for a couple projects that are now in production. It helped clarify how to structure workflows.
Agree that the cookbooks have gotten messy. Not an excuse but sharing the root case behind it: we're building very, very fast and putting examples out for users quickly. We maintain backwards compatibility so sometimes you see 2 examples doing the same thing.
I'll make it a point to clean up the cookbooks and share more examples under this comment. Here are 2 to get started:
- Content creator team: https://github.com/agno-agi/agno/blob/main/cookbook/examples...
- Blog post generator workflow: https://github.com/agno-agi/agno/blob/main/cookbook/workflow...
Both are easily extensible. Always available for feedback at ashpreet[at]agno[dot]com
The way agent construction is laid out (with a clear path for progressively adding tools, memory, knowledge, storage, etc.) feels very logical.
Definitely lowered the time it takes to get something working.
Thankfully your third example half way down does have an eg with 3 agents. May have helped to have a judge/architect agent.
Not clear about the infra required or used.
Would help to have helper functions to get and set session state/memory. Being able to bootstrap from json could be a good feature.
Would help to have diff agents with diff llms to show that you have thought things through.
Why should spawning 1000's of agents even be in your benchmark. Since when did we start counting variables. Maybe saying each agent would take X memory/ram would suffice - because everything is subjective, can't be generalized.
Consider a rest api that can do what the examples did via curl?
Good luck!
JimDabell•8mo ago
This strikes me as odd. Aren’t all these agents pushing tokens through LLMs? The number of milliseconds needed to instantiate a Python object and the number of kilobytes it takes up in memory seem irrelevant in this context.
sippeangelo•8mo ago
bediashpreet•8mo ago
Another example: there a large, fortune 10 company that has built an agentic system to sift through data in spreadsheets, they create 1 agent per row to validate everything in that row. You might be able to see how that would scale to thousands of agents per minute.
gkapur•8mo ago
bediashpreet•8mo ago
- High Performance = Less Bloat: As a software engineer, I value lean, minimal-dependency libraries. A performant framework means the authors have kept the underlying codebase lean and simple. For example: with Agno, the Agent is the base class and is 1 file, whereas with LangChain you'll get 5-7 layers of inheritance. Another example: when you install crewai, it installs the kubernetes library (along with half of pypi). Agno comes with a very small (i think <10 required dependencies).
- While inference is one part of the equation, parallel tool executions, async knowledge search and async memory updates improve the entire system's performance. Because we're focused on performance, you're guaranteed top of the line experience without thinking about it, its a core part of our philosophy.
- Milliseconds Matter: When deploying agents in production, you’re often instantiating one or even multiple agents per request (to limit data and resource access). At moderate scale, like 10,000 requests per minute, even small delays can impact user experience and resource usage.
- Scalability and Cost Efficiency: High-performance frameworks help reduce infrastructure costs, enabling smoother scaling as your user base grows.
I'm not sure why you would NOT want a performant library, sure inference is a part of it (which isn't in our control) but I'd definitely want to use libraries from engineers that value performance.