Transcription
This is an interview with the founders of AutoGen, Dr. Xi Wang and Dr. Shing Yun Wu. Dr. Wang is a senior staff researcher at Google DeepMind, and Dr. Wu is an assistant professor at Penn State University. Both of them are responsible for the creation of the original AutoGen and now AG2.
So, we're going to talk about everything from agents to open source and so much more. Let's get into it!
I would love to hear about the origin story of AutoGen. I know, as you've told me, it's a collaboration between Penn State and Microsoft. But how did that come to be? What were you both working on prior to that, and then how did you meet each other? How did you start that project?
Yeah, thank you, Matthew, for asking that. Yes, indeed, when AutoGen was created, I was at Penn State University and the team at Microsoft Research. Before that, we were both working on another open-source project called FL. It is a library for automated machine learning and hyperparameter tuning. CH and I have been working on that project for over five or six years. We started that project in 2019 when I was interning at Microsoft Research with CH. My intern project was about hyperparameter tuning, and we invented a very efficient hyperparameter optimization algorithm. We decided that we should make it open source to benefit others, and then we released this FL library. Since then, we have been working on this open-source project, starting from 2019, and we have also been building a community around FL.
Actually, I'm not trying to advertise FL here, but FL has been adopted by many enterprise users, especially in the fintech industry. Many banks have this table data, and they have this very efficient automl library. There has been a lot of adoption; we have millions of downloads of the FL library. So, we have been working on this FL project, and then we saw the huge potential of generative models. We have been thinking about how we can empower people using large language models and those generative and foundation models. Perhaps CH can tell a little bit more about how we reached this idea.
Yeah, sure. As Jim mentioned, we were both working on FL, using AutoML techniques to help data scientists and machine learning engineers choose the best model for their applications. When GPT-3 came out, it was a very new kind of model with new capabilities. So, a natural idea for us was to try the AutoML technique to tune the inference parameters of the GPT models and see how much that matters.
It turned out it mattered a lot. For several problems, like math problem solving, coding, and other text generation tasks, we found that choosing the best inference parameters can make the model perform well and also minimize their inference cost. That's when we realized there was a big opportunity to best use these models and maximize their utility for different applications.
It's not simply just putting in the model, doing the inference once, and getting the job done. There often involve multiple influences and multiple other steps—not just about using the models, but other steps like using tools or getting human inputs and so on. So, it's a big design space. Based on our experience with AutoML, a natural idea was, can we help developers easily navigate that large design space quickly and provide the optimal solution?
But before we can do that, we first need to have a solid fundamental framework. Just like in the machine learning area, we had some standard machine learning frameworks like Scikit-learn, PyTorch, Hugging Face, and so on. Those provide a simple interface to easily navigate a large design space. Then, on top of that, we can apply some automated machine learning techniques to automate that process of optimization.
At the time we started building AutoGen, there was no good unified framework yet, so we decided to build one ourselves. That's the motivation for starting to build AutoGen.
When did you first see the potential of agents collaborating with each other? Because when I first saw AutoGen, it was one of the first times I had even thought that, hey, if you allow one agent to communicate with the other, they can correct each other's work and iterate on an output before giving you the final output. So, it was somewhat new to me. When was the first time that you had that "aha" moment and saw the potential of agents working together?
Shall I answer, or do you want to go first?
Yeah, I can briefly talk about my "aha" moment. At that time, we were trying to solve some math problem-solving issues. We chose math problems because, first, they are important, and also they are very challenging. Another reason is that they are easier to evaluate. And I like math; I'm also an educator, and I care about education. I was thinking about some applications related to math tutoring.
When we tried to solve very challenging math problems, we found that we typically needed to involve tools and sometimes write some code to do some calculations. When it involves code, we found that we needed to do this iterative coding—code generation and debugging, code execution, and this back-and-forth debugging. We found it would be very handy to have an executor agent that can execute the code.
On the other hand, we may want to involve a human in the loop. For example, we may want to involve an actual human tutor to help the student when the model cannot help. So, combining these two, we came up with this user proxy agent idea. The original motivation for that was to mimic what a human would do when interacting with, for example, ChatGPT. At that time, ChatGPT could only generate code but could not execute it.
If you interact with ChatGPT, the human user would need to copy the code, run it, get the result back, and then continue the conversation. So, it's basically mimicking what an end user would do. That essentially forms two-agent chat: one is the assistant agent, a large language model, and another user proxy agent trying to mimic what a human would do.
This whole process is fully autonomous; you can see these two agents autonomously going back and forth, debugging and chatting with each other to solve the task. It's really fascinating. For me, the starting point is really ChatGPT. I think ChatGPT is a big step forward compared to the previous GPT-3 models, just doing text generation. But ChatGPT is really the time that it got significant impact from the general public.
I think the reason for that is that this chat interface allows natural participants of humans to provide feedback when something goes wrong. They can back and forth iterate over that. When I think about that, I immediately relate this to some of my personal experiences in college. When I took a seminar in quantum computing and quantum communication, my professor, Rwan, gave me a lesson. He told me that conversation or dialogue is a proper way to make progress in creating new knowledge, proving new knowledge, and generating new learnings.
That has a deep theoretical ground in that process. When I think about why ChatGPT has huge success, I think it's a very good demonstration of that theory, but in a very new technology. Now we have models that are very capable of doing conversation—not just humans. That has a huge communication potential.
It starts as communication between AI and humans, but there's no reason to prevent us from using AI models to converse with each other. Of course, humans can still be involved in the conversation, but not necessarily just one human versus one AI model. Later, we see GPT-4 pushing that capability to a higher level. The models demonstrate many more capabilities, including reasoning, strong reasoning, planning, and debugging. Each of these capabilities can be configured for different agents to play different roles.
Even the whole process of generating code, doing testing, reviewing, and then reverting back—there's a whole loop of workflow processes. If we think about enlarging the scope of the way we're using the language models at that time, we try to include more steps or more processes in the loop and have the models automate as much as we can. Then the level of complexity of the tasks we can achieve will be much higher.
I was thinking about several concrete applications. Some of them are like data generation, but usually, we need to have one agent to address the request from a user. The user needs to provide input, but if we replace the user with an AI agent, then possibly we can automate that data generation process and generate a lot of different kinds of training data corresponding to different personalities or backgrounds and collect a large amount of useful data. That's just one simple example application.
Before I jump into the application, I thought this can have a huge impact. If we generalize this pattern, it has big implications and big opportunities to model much more complicated processes. As CH mentioned, we took the math problem-solving as one initial case study. After we had a very deep understanding of that and made the two agents work with each other, by the way, the two agents are one assistant agent simulating the ChatGPT backed by GPT models and another user proxy agent that simulates human behavior, including generating and executing code suggested by the AI agent.
Different modes from the user proxy include automatic execution or manual feedback. After making that two-agent conversation paradigm work really well, we also took some feedback from initial users and found that there was a need to generalize this conversation pattern to accommodate more agents, more different roles, and also different communication patterns. We quickly evolved from a simple two-agent communication to more agents, and that's where the magic started.
I'm going to ask you a little bit about some of the best practices that you've discovered over time, but I want to save that for a little bit later. Once you started working on the original AutoGen, how long were you building until you first published publicly?
That's a good question. The thinking started much earlier—around late 2022—when we were trying to tune the parameters for the models. As we started to think about the right abstraction to accommodate this very large design space that includes models, tools, and humans, and all the different types of entities together, it took several months to figure out the right way to do it.
Around the time when GPT-4 was released, in April 2023, that was the real starting point to use agents as the abstraction to start building the agent framework. From then until August, we were heavily working on building the agent framework, getting initial feedback from users, and iterating. I think in August, we wrote the first research paper.
Oh, please, please.
That's about the timeline—like several months to build the initial version of AutoGen and also provide some case study application study and put that study into that paper. In total, actually, it's not that long; it's just several months—three to four months.
One thing I want to—sorry, no, please.
In terms of being public, it's actually public since the beginning. Since April, when we wrote our first line of code, it was written in the open-source FLAMEL project. So, every single line was written publicly. But we didn't write down anything to report, so most people didn't find it. But the FL community had some early access to AutoGen—our smaller FLAMEL community.
When the more mainstream, like myself, first got eyes on this, what was—I mean, I know what my reaction was and kind of the folks I was speaking with about it, but what was the feeling for you both like when you put it out there? I assume people were just stunned by it because it was just so interesting and so different than anything I had seen before. What was that feeling like in those first couple of weeks after publishing?
To be honest, I never imagined this would happen. I was just working on my idea and working on our idea and wanted to make it useful. I didn't imagine this could be so popular. I was very shocked, and of course, in a good way. I was very motivated to make it much better. That's my reaction.
Let me tell you some story, Matthew. I set a one-year goal for the AutoGen project when I spun it off from FLAMEL. I set a specific number of stars on GitHub for AutoGen.
I knew you were going to say a certain number of stars!
Let me guess—1,000 stars?
Yeah, exactly! Because based on our FLAMEL experience, we were growing in the community steadily but also incrementally. We talked to every single user of FL since the beginning, and we did a lot of iterations each time. So, it's been a very manageable path of community growth. But AutoGen is totally different. Just within a few days after release, I realized I needed to change my goal one year ago after several days.
That's amazing!
I just looked, and it is currently at over 35,000 stars.
So, no big deal!
That's amazing! I want to talk to you both a little bit about open source. Obviously, maybe not obviously, but in academia and especially at Microsoft Research, open source is a big part of it. However, I don't think, at least on the enterprise side of things, people have adopted open source like they have in the AI community. I'm really excited about that. This is something I've been thinking a lot about lately.
Personally, prior to diving headfirst into artificial intelligence, I was not very knowledgeable about open source and the value that it brings. So, talk to me a little bit about your journey to open source. Have you always been into open source? Was it just not a question—like obviously we're going to be publishing, so we need to publish the code as well? Was it a decision to make AutoGen open source, or was that just the default?
I can share my journey in the open-source world. It's not a smooth one since the beginning. It's kind of more like a very coincidental or incidental journey for me to get into that world. For the initial multiple years of my work at Microsoft Research, I was mainly just working on techniques, writing research papers, and occasionally talking to product teams to ask them to use it. But I never did any open-source work.
The first time we did that was for the FL project, and I think I was very lucky to make that call. But it wasn't open source from the beginning. At first, we followed our previous playbook. We did some theoretical study, proved some theories, and then wrote a research paper about it. At that time, I think not many people knew about that FLAMEL work or AutoGen work until someday a user reached out. They found a paper and really wanted to try it out. They wanted us to share the code, but we didn't have ready-to-share code at that time. We had some research prototype, but we tried to offer a private license—not open source—to that initial user, although they preferred open source.
So, that was the first try. Because at that time, the code was more like research prototype quality; it was not ready to be adopted right away. After some time, another user reached out again after reading the paper, and again they asked whether we had an open-source offering. That's when I thought, okay, we couldn't wait any longer. We should do open source as soon as possible; otherwise, this same pattern may repeat.
Because we didn't have experience at that time, we were not sure whether it was a good idea or how much it would help. Would this really lead to large-scale adoption? We didn't have the answer, but at least for this one user and maybe the previous users, they had this requirement and need. We didn't have any better alternative, so let's just do it.
That opened the door to this new world, and since then, we have learned so much in that journey. Every time we addressed some users' concerns, we made the library much better in terms of usability, and it also drove a lot of follow-up research work in the multiple years following that. The library got better and better, and adoption increased from small to medium-sized companies to large-scale companies, including some big products in Microsoft and other companies.
By the time we started building AutoGen, I think that lesson was already very clear to us. The timing—both the decision about doing open source and also the timing to do it—was driven by our previous lessons from building FLAMEL. You can see that this time we took a very different approach when building AutoGen. We wrote the first code, and everything since the beginning was open source. That ensured the fastest speed to get initial user feedback and for citations.
That didn't slow down the adoption from enterprise companies; rather, it accelerated that. We have learned a huge amount of enterprise use cases and adoptions after it got awareness in the open public.
And yeah, this was a big learning for me, at least personally.
Jun, what do you think was your journey?
Yeah, I'd also love to share my journey. There are roughly three stages. I used to be a PhD student, and when I was doing my PhD, the default mode was to share code and make my research available and accessible to others for many reasons, like reproducibility and making an impact. That was kind of the default mode, and I didn't think too much about it.
It's probably because of my PhD advisor; he had kind of this high standard, and we wanted to make our research reproducible and let others audit our research. So, that was kind of the naive default period. Then we worked on the FL project, and we actually saw some enterprise adoption and much more usage from users compared to my PhD research. We had millions of downloads, and at that stage, I saw that my research was making an impact. I could see the impact it made; people were using this in their real-world use cases, and it felt very fulfilling as a researcher.
At the AutoGen stage, we had much wider adoption and visibility. At that stage, of course, I very much appreciate the passion and interest from the users of AutoGen. That allows me to think about contributors and users and what it means to have this open-source library and what can benefit contributors and users.
I think open source is really a very healthy ecosystem. For contributors, they can make their research and contributions accessible to others and can also build based on others' contributions and make it available to the world. For users, especially for enterprise users, I think one important thing that open-source software brings is transparency and trust because all the code is available, and everyone can look at it.
So, there is a natural transparency there, and also there is a kind of sharing spirit—if there is something good, we should share it with the world to benefit the whole world. That's another benefit. Another kind of benefit to the enterprise is that open source can grow very large and can grow a whole community and ecosystem, making it easy for their employees to use it. For example, if a lot of people are already using the software infrastructure, when they onboard new employees, it's easy to let them use this software and start building instead of learning some software that is only specific to their internal team. I think this is a very healthy ecosystem.
I really appreciate, first of all, you both for contributing to open source. I also think there's something special about the AI industry where, maybe because it is so raw right now or maybe because so many people who are trying to build things also come from research and academia, open source feels like the default, which is really nice. Obviously, you both were big contributors to that momentum, and it just feels really cool.
It's just not something that I'm used to, and so I really like being able to go and look at the code, download it, play with it on my own computer, tinker with it, change things that I don't like, or enhance things that I do, and potentially submit those enhancements for other people to benefit from.
On that, I want to talk a little bit about agents. Let's talk about some practical matters for the folks listening. A lot of the people who watch my channel are builders—they're tinkerers, they're builders, they're at companies, they're building their own projects on the side, and they want to use agents. What are some of the best practices that you've seen from AutoGen and agents in general that people should think about? Whether that's the types of models to use, the number of agents, how verbose the prompts or the system messages should be—what are some of those very practical, very tangible best practices that two agent experts would give to the audience?
Shall I start, or do you want to start first?
Yeah, I can give some of my thoughts, which probably are not unique, but I really feel starting with prototyping and having one single instance of the task work is a very good starting point. It's also a very rewarding experience, and it allows you to experiment with different approaches. I think that's generally a very good starting point, at least based on my experience.
The best practices definitely evolve over time. In the beginning, when we had the initial version of AutoGen, we had some guidelines in the technical report we wrote. It said to begin with a simple setup of maybe two agents—just one assistant agent where you can put all the instructions about the things you want the AI to do, and make another agent called user proxy and give it the right capability, like code execution, depending on whether you need that. Start experimenting with that setup.
When the task is simple enough, that two-agent setup can work quite well already. When the task is complex, then you will see that a single model agent cannot follow all the instructions nicely, forget instructions, or not do certain steps in a very high-quality way. That's the time you may need to think about breaking down the task into smaller pieces and have specialized agents focusing on the simpler tasks so that for each step, they can finish with higher quality.
When you do that, you also likely need to think about the topology of the communication among these multiple agents. For a simple two-agent setup, it's just taking turns: I say something, you say something. But once you have more than two, the number of choices becomes very large—actually infinite.
Just think about the three of us speaking; the order of this can be infinite. You can have patterns like ABC, ABC, or AAB, AB, AB, C, or ABC, AA, AB, A, B, C. So, there needs to be an intuitive and natural way for multiple agents to work together. We provide a few basic conversation patterns or building blocks, including sequential chats, multi-agent chats, and group chats. Depending on how much control you want in the workflow, you can choose or mix them for different purposes in different sub-parts of your workflow.
There are patterns with more flexibility and patterns with more controllability. There are also patterns that can help you isolate the work from one agent to another, like in chat.
Regarding the models or tools used, when you have multiple agents, you have more freedom to choose different models, give them different configurations, or provide different tools for each of them to make the best out of it. It actually makes it easier to optimize for multiple metrics as you want. Sometimes you want to maximize quality, but in some cases, you also want to bring down the cost or latency, and you can do that with multiple setups.
Some other guidelines may evolve over time. I also have some even more recent suggestions or guidelines corresponding to the new features in AG2. These practices are related to two important features in the new version of AG2: one is called Captain Agent, and the other is called Swarm Agent. They represent two different practices, both of which are needed in most cases.
The Captain Agent represents a paradigm of a fully automatic way of creating agents and agent teams tailored to a specific task. Users just need to provide a task to the Captain Agent, and it will analyze the task, decompose it, and then create different agent teams on the fly for each step in the process. The entire process can be automated; users just need to provide the input task, and all the intermediate steps are automated.
Users can also look at what agents are created or selected from the existing library. They can utilize existing agents or tools or create new ones on demand. That's one paradigm.
For relatively simple tasks, that can work well. When the task is too complicated or we don't have enough tools or agents already provided, it may fail to generate the right tools. But often, it will give you part of the solutions, and then users or developers can look at what is suggested and take whatever is useful as a starting point, adding some missing pieces.
It can be some missing tools to add or some missing agents of particular roles that only the domain experts know, but currently, the Captain Agent doesn't know.
Then, developers can use the created agents and combine that with the Swarm pattern. The Swarm is like a high-level program interface similar to the Open Swarm framework, but combined with all the rich functionalities within AG2. All the conversation patterns can still be programmed using one pattern but in a more intuitive and simpler way.
Now, you can take the agents from the Captain Agent and make them work together as one pattern, defining the necessary transitions or instructions about how to hand off to different agents. They can also share some context variables and share information in a more structured way, leveraging the new structured output features from AG2.
These two different kinds of very useful ways can be combined together in your development process. That's the latest kind of suggestion or guideline I think can be used as best practices. But over time, we will probably discover more and share more.
Actually, another kind of general guideline I find useful is to think about how human organizations solve problems. I think it's reasonable to treat a language model as a human with probably medium intelligence. We have already developed ways to approach different problems. For example, for handling HR, typically in a company, you may have an HR team, and there are probably different functional roles for handling HR. I think mimicking what human organizations would do is a generally good starting point.
As a quick follow-up, we talked a little bit about best practices, and one of the best practices that I frequently get asked about is human in the loop. When is the right time for the human to be in the loop? What have you seen in terms of your own projects or other more complex enterprise-level projects? What is the right time for the human to be in the loop? Is there a standard definition of certain complexity or a certain importance of a decision? How do you define when that should be involved?
I have some initial thoughts; I can take the first and can add to that. I think depending on the technology advancement, the type of involvement from humans can vary. If we think just very far ahead, if we think about the end game—let's say the agents can have capabilities so strong that they can finish pretty much all the tasks we want them to finish—what do we still need from humans?
That's the minimal kind of things we want humans to get involved in. Then there's the question of when the AI is not perfect, when they haven't reached the level of intelligence we want them to be. What are the other things we want humans to do?
There are two parts to this question. For the first part, what are the minimal kinds of things we want humans to be involved in? I think there are several important things. For example, the intent—the original intent from humans about what kind of task we want to accomplish. I think that really needs to originate from humans.
Even though sometimes we can imagine a world where AI can also actively make suggestions without humans initiating the request, humans still need to make a decision about whether they really want that. The call for the initial request really needs to start from humans.
After that, it's often not just once; it's often not just providing one initial intent and letting AI do everything else. There's natural ambiguity in how we express what we want. We often choose to say something short, but there can be a lot of clarification needed from the agent. So, likely, we also need to iterate a few times until that intent is very clear for the AI to execute.
So, that's the second thing I think humans need to be involved in. The third one is that once the AI returns with certain results or actions, if the result is not exactly what we need, or when there's a need for human verification, humans need to look at the result and provide feedback if anything is left to be further addressed.
The fourth one is that sometimes humans need to override the decisions made by the AI agent and take over when it becomes necessary. These are the four very basic elements that likely require human involvement.
But depending on the quality of the AI techniques or agent capabilities, the degree can be more or less for each of them. For example, if the AI agent can always return with the best quality and satisfactory results, maybe the feedback part can be less involved, and so on.
This is some basic analysis, and I feel like there are several other interesting things to think about beyond this. For example, teaching. If the AI lacks the knowledge or skills to handle some very specific tasks, some amount of teaching is required. We can imagine building teachable agents where humans will teach them the necessary information or knowledge, and then they can iterate over time and become better.
After a while, they can use the lessons we give them to do follow-up tasks, but initially, this interaction from humans is needed to do the necessary teaching.
Also, think about the opposite side of that: learning. Even when agents can do the tasks, humans still have an interest in learning how they did them—both for curiosity and sometimes for ensuring correctness. Sometimes, they want to gain skills themselves. The human wants to become better, so they can vice versa learn useful skills from AI agents. I think that's also a natural incentive for humans to keep engaging with agents.
I appreciate all of those; I think they make sense. I want to change topics for a moment. You've both recently forked the original AutoGen code and started AG2. I would love to hear about what led to that decision. Shing, why don't you start and tell me why you decided to fork the code? Was there something that wasn't working for you within the environment that it was previously in? What did you want to do, and where do you want to go with AG2?
Thank you, Matthew, for asking that. Yes, actually, as we kind of discussed, the AutoGen project has been a collaborative effort between Microsoft and many other contributors, including myself at Penn State University. There are also other students from other universities.
At the beginning, we decided together that we were okay releasing the code under the Microsoft organization because it is still open source and under the MIT license. We thought that was fine, and it worked well for a while—over a year. We have been working together well at the beginning, but as the project grows, there are complexities.
First of all, in terms of managing the project within Microsoft, there may be some people who want to take the project in a particular direction, and there is involvement from leadership as well. I think you understand that in big corporations, there are a lot of factors that affect how a project may go. I'm not saying it's bad; it's just a reality, and it actually slows down the project a lot.
A lot of times, our progress was slowed down, and there were external contributors.
If I can interrupt for one second—speaking of speed, I feel like every other day I'm seeing a new post on X about a set of new features for AG2. Whatever has changed between AutoGen and AG2, the reins are off. You guys are moving so fast; it's so impressive. Sorry for the interruption; please continue.
Yeah, thank you for pointing that out. That's one of the primary considerations. We want to move fast; we want to have the autonomy to make decisions and move forward together with the community instead of getting trapped by many other factors.
That's one important factor. Another factor is making it grow AutoGen in a more neutral place, which makes it more convenient for others to contribute. There are many contributors from other big companies who may not want to contribute to a project that is living under Microsoft. That's another reason we wanted to make it much more convenient for others from all organizations to contribute to the project.
Those are the two main reasons. Thank you for mentioning that we are making much faster progress, and we are indeed very happy and excited about it. Our community engagement has grown a lot as well. We now have contributors from Google, Meta, and actually from Microsoft as well, and also from IBM and other small companies and universities. The community energy is super fascinating.
Okay, so you're building AG2 now. By the way, for everybody watching, I'll drop all of the links to the GitHub, the main website, and everything in the description below. What are your short-term and long-term plans? What are the things coming that people should be excited about?
Short-term plans? Yeah, I can disclose that; probably that won't spoil the surprise. First of all, we want to keep it a community-driven project. We are constantly soliciting feedback and advice from the community and, more importantly, from our users on what we should do next. This is generally our principle right now: we want to use case-driven development. Whatever is needed from the use cases, we will try to add that and support it.
Right now, we are extending—like CH mentioned, we recently released Captain Agent, Swarm Agent, and Knowledge Graph, along with structured output. We have a lot of updates already. In the short term, we are planning to expand AutoGen to AG2 to real-time applications, to better support these real-time use cases, for example, real-time voice agents. That's something that I feel very excited about in the short term.
One thing that seems obvious that's going to be coming in the future, but really hasn't been here yet, is agents that are proactively accomplishing things on your behalf. You know, the agents, I think, do a lot right now, but you have to tell them, "Hey, go do this thing," and they don't necessarily have easy access to your personal information or corporate information. You kind of have to set all of this up.
When do you think we're going to be at a point where agents are more autonomous, more proactive, and accomplishing things on your behalf 24 hours a day?
That's a good question, and that's a very exciting question to think about because it opens up so much time for a person. I think, in terms of technology, we are very close or already very close to reaching that.
One tricky part is the human interaction interface—the UI/UX. Although we want the agent to autonomously finish tasks, we still want to have the right authorization mechanism. For example, I don't want the agent to send out an email that I don't like. It's nice that it can send an email on my behalf, but if it's a very important email, I hope to review it first.
I think this human-in-the-loop mechanism needs to be in place, and that contract or protocol needs to be established or well-designed. Then we are very close. I think probably somewhere on Earth, someone has already invented this fully autonomous system.
What do you think?
For special domains, I agree that the technology-wise, there's no fundamental blocker. I've seen tasks that take a lot of time to run, and currently, agents are able to keep running. After they finish the work, they return the result. The only thing that's different from what you described is that the user needs to provide the initial request.
But that step is supposed to be automatable as well. We have another agent that plays the role of the user, sending that request. Once in a while, it simulates what the user will say and then triggers the remaining of the agent team to do the work.
If there are no constraints in computer resources or if you don't need to worry about the bills, that is doable. But I think there are several reasons we haven't seen that running in real life. One is, aside from the cost concern, the quality is not guaranteed.
Because when users send requests, they clearly know this is a task they want to accomplish. When the agent does it for the user, we don't know whether they always do what we want. Maybe it works well for a week, but the next day it does something unwanted, and it may cause some very undesirable consequences. We don't know who should take responsibility for that.
That's similar to maybe the self-driving car. I think the technology-wise, we have very good technology, but for many regulation requirements, there are questions about how to clarify who takes responsibility. So many concerns like that prevent it from getting used.
But if it's one individual and the individual takes all the responsibilities for themselves, they potentially can already do this. After the technical viability, the next question is whether we really want that.
I think in my outlook for maybe the next five to ten years, we should be able to get to a world where agents can finish most of the tasks from the idea suggested by humans to nice results with minimum human supervision. But at that time, we still want to make sure that if we want to delegate tasks to agents, we can, but if we want to do things ourselves or take over ourselves, we can. I think that's very important to guarantee.
Before that guarantee can be made, there will always be this question: can we really let it go?
Also, I think there are still questions about whether we really want that.
I'm really excited to see what the future of AG2 is. I've said it a million times; I'm kind of known for saying I'm bullish on agents. I'm waiting for the time when agents can connect to my personal accounts and really accomplish tasks. I think Shing, you mentioned specifically that you don't want agents to just write an important email and send it, but to draft it and have it ready for me to review and send. That would save me an immense amount of time.
I want to thank you both very much for spending the time with me today, chatting with me. This has been fascinating. I also want to thank you once again for contributing to open source and really starting the agent framework wave. There are a lot of exciting things coming. I'm going to drop all of the links in the description below, but once again, thank you very much for chatting with me today.
Thank you very much, Matthew, for having us.
Yeah, thank you very much! It's great talking to you, and it's a very unique experience.