SuperAGI VS autogen

Repo : https://github.com/TransformerOptimus/SuperAGI

The recent introduction of the “Agent Summary” feature in SuperAGI version 0.0.10 has brought a drastic difference in agent performance – improving the quality of agent output. Agent Summary helps AI agents maintain a larger context about their goals while executing complex tasks that require longer conversations (iterations).

Checkout the full release here: https://github.com/TransformerOptimus/SuperAGI/releases/tag/v0.0.10

10. SuperAGI

Currently, PaLM2 Bison is live on the dev branch of SuperAGI GitHub for the community to try: https://github.com/TransformerOptimus/SuperAGI/tree/dev

SuperAGI is made with developers in mind, therefore it takes into account their requirements and preferences when making autonomous AI agents. It has a number of advantages, including:

I think for agents to truly find adoption in real world, agent trajectory fine tuning is critical component - how do you make an agent perform better to achieve particular objective with every subsequent run. Basically making the agents learn similar to how we learn when we

Also I think current LLMs might not fit well for agent use cases in mid to long term because the RL they go through is based on input-best output methods whereas the intelligence that you need in agents is more around how to build an algorithm to achieve an objective on the fly - this requires perhaps new type of large models ( Large Agent Models ? ) which are trained using RLfD ( Reinforcement Learning from demonstration )

Also I think one of the key missing piece is a highly configurable software middle ware between Intelligence ( LLMs ), Memory ( Vector Dbs ~LTMs, STMs ), Tools and workflows across every iteration. Current agent core loop to find next best action is too simplistic. For example if core self prompting loop or iteration of an agent can be configured for the use case in hand. Eg for BabyAGI, every iteration goes through workflow of Plan, Prioritize and Execute or in AutoGPT it finds the next best action based on LTM/STM, or GPTEngineer it is to write specs > write tests > write code. Now for dev infra monitoring agent this workflow might be totally different - it would look like consume logs from different tools like Grafana, Splunk, APMs > See if it doesnt have an anomaly > if it has an anomaly then take human input for feedback. Every use case in real world has it's own workflow and current construct of agent frameworks have this thing hard coded in base prompt. In SuperAGI( https://superagi.com) ( disclaimer : Im creator of it ), core iteration workflow of agent can be defined as part of agent provisioning.

Another missing piece is notion of Knowledge. Agents currently depend entirely upon knowledge of LLMs or search results to execute on tasks, but if a specialised knowledge set is plugged to an agent, it performs significantly better.

Build your own game here: https://github.com/TransformerOptimus/SuperAGI

I am still playing around with the project but FYI, the parsing for the github repo URL at https://glide.agenticlabs.com/ will fail if there's a trailing slash in the repo link i.e. https://github.com/microsoft/autogen/ won't work but https://github.com/microsoft/autogen will.

New example notebook demoing video transcript translate with whisper.

New release: v0.2.1

I disagree with the conclusion. In software, I've seen 10x engineers in person and I don't think they're replaceable. Whereas, the new college grad or that entry level dev who doesn't design anything and just writes small amounts of code, doing exactly as told is replaceable by an AI. Frameworks similar to Microsoft Autogen(https://github.com/microsoft/autogen) can in theory build agents who can do these tasks with ease whereas a 10x engineer can focus on directing the agents and designing systems.

Microsoft autogen

CompressibleAgent (experimental) can be used to handle long conversations. Notebook: https://github.com/microsoft/autogen/blob/main/notebook/agentchat_compression.ipynb

Added a simple Testbed tool for repeatedly running templated Autogen scenarios with tightly-controlled initial conditions. by @afourney in #455