Bring AutoGen to dotnet

[LittleLittleCloud]

trafficstars

any insights on how to introduce AutoGen to the world of dotnet? It would be truly exciting to witness the potential of multi-agent collaboration in helping dotnet developers to create highly intelligent applications.

@sonichi @luisquintanilla @JakeRadMSFT

Update on 2024/02/12

Nightly build are available to public.

checkout the following link on how to consume night build packages

• https://microsoft.github.io/autogen-for-net/articles/Installation.html

Update on 2024/02/08

Temporarily suspend publishing to github package until PR merged in main

Update on 2024/01/31

~AutoGen nightly build is also available on github package~ ~feed url: https://nuget.pkg.github.com/microsoft/index.json~

~To consume github package, please refer to the following link~ ~- https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry#installing-a-package~

Update on 2024/01/23

AutoGen for dotnet preview is available internally. We are working on the process of publishing to a public feed for external customers. I'll update the progress once it's available

Doc (preview)

nightly feed (update for every new commit): https://devdiv.pkgs.visualstudio.com/DevDiv/_packaging/AutoGen/nuget/v3/index.json

Migrate from AgentChat

• Replace AgentChat.Core with AutoGen.
• If you are using AgentChat.DotnetInteractive, replace it with AutoGen.DotnetInteractive
• Adding reference to AutoGen.SourceGenerator for type-safe function call
• Fixing build errors. API mapping from AgentChat to AutoGen should be fairly straightforward, if you encounter any issues please let me know.

Update on 2023/12/04

Start porting C# AutoGen

PR: #924

Update on 2023/11/13

Support OpenAI Assistant API

Update on 2023/10/22

I'm going to answer my own question here.

I have recently developed a dotnet-version AutoGen, with both code and packages available on GitHub at the following repository: [AgentChat](https://github.com/LittleLittleCloud/AgentChat.

To utilize the package, simply add the nightly build feed from the following URL:

https://www.myget.org/F/agentchat/api/v3/index.json

The features currently supported include:

• Connection to OpenAI models
• Two-agent chat
• Group chat
• Function calling

However, some functionalities are not yet available, such as:

• Python code execution
• Support for LLMs other than those mentioned

Moreover, AgentChat provides some unique functionalities thanks to dotnet feature

• typed FunctionCall using source generator: automatically generate FunctionDefinition based on structural comments.
• Dotnet code execution: run dotnet script on dotnet interactive.

Here's how to add the package:

<ItemGroup>
    <PackageReference Include="AgentChat.Core" />
    <!-- Adding AgentChat.GPT will enable connection to OpenAI models -->
    <PackageReference Include="AgentChat.OpenAI" />
</ItemGroup>

Further Notes

• Please note that this SDK is still in its nascent stage and as such, there's no stable version released yet.
• The following steps will involve introducing additional notebook examples, and expanding support for other LLMs.
• Collaborative contributions are always welcome.

[luisquintanilla]

Makes sense to me especially the potential for integration with existing .NET libraries and tools.

From a repo / ownership perspective I'm happy to follow the AutoGen community lead here.

[sonichi]

Step 1 could be: test how well C# works with LLM. For example, create a C# coding agent by modifying the default system message of AssistantAgent, and a C# execution agent by extending execute_code in code_utils.py to support C# code.

It that works well, Step 2: ask autogen agent to convert python code to C# :)

[LittleLittleCloud]

@sonichi

Step 1 already been tested. MLNet-task-101 is fully driven by a dotnet implementation of dynamic group chat

For step 2: That would be a really interesting idea. If the method has been proved to work well, we can simply copy-and-paste the methodology over other machine learning python libraries, convert them into dotnet, and Luis's dream (and mine as well) would become true

[sonichi]

Nice. A PR with C# agents is welcome.

[colombod]

I am considering making that PR !

[subhankars]

Bring AutoGen to Semantic Kernel

[dazinator]

Would the user proxy agent have to be extended so that it could recognise and execute c# code as opposed to python?

Dotnet has a docker image for a runtime as well as the sdk, so it would also be really nice if the code can execute via the docker container.

[LittleLittleCloud]

@dazinator No IMO, we can just provide a function_call called run_dotnet and let llm decide how to execute the code.

And it takes extra steps to run a piece of dotnet code if we want to utilize dotnet sdk? dotnet interactive would be a better choice here (or dotnet script) as it doesn't require a project to be created before running a piece of code.

[dazinator]

@LittleLittleCloud dotnet interactive looks good. It does appear to execute a different dialect of c# than "standard" c# though, not sure whether that would need any special consideration.

I thought of docker just as means to employ or control the build and execution environment. Its common in dotnet projects to use docker multistage builds - so a dockerfile has a build stage which uses the sdk image to compile the code, and a run stage which uses the runtime image to execute those binaries. The run image could be pushed to a container registry for onwards deployment for example.

I guess I'm too new to this project to decide if any of that is really desirable in this case. It sounds like dotnet interactive could make that all go away.

My dream use case for autogen would be that I'd want to use it to develop simple dotnet command line applications that could be onwards deployed. For me this would mean not only producing c# code to fulfil a certain task but building that code (so via the dotnet sdk) and running it, testing it etc. It's not typical to build run and distribute professional dotnet apps as 'dotnet interactive' apps. Perhaps this is me getting confused with the code interpretor capability in autogen, vs what you can actually achieve with it 🤔

[LittleLittleCloud]

@LittleLittleCloud dotnet interactive looks good. It does appear to execute a different dialect of c# than "standard" c# though, not sure whether that would need any special consideration.

I thought of docker just as means to employ or control the build and execution environment. Its common in dotnet projects to use docker multistage builds - so a dockerfile has a build stage which uses the sdk image to compile the code, and a run stage which uses the runtime image to execute those binaries. The run image could be pushed to a container registry for onwards deployment for example.

I guess I'm too new to this project to decide if any of that is really desirable in this case. It sounds like dotnet interactive could make that all go away.

My dream use case for autogen would be that I'd want to use it to develop simple dotnet command line applications that could be onwards deployed. For me this would mean not only producing c# code to fulfil a certain task but building that code (so via the dotnet sdk) and running it, testing it etc. It's not typical to build run and distribute professional dotnet apps as 'dotnet interactive' apps. Perhaps this is me getting confused with the code interpretor capability in autogen, vs what you can actually achieve with it 🤔

Ha I see, so you are seeing a larger picture than I was. dotnet interactive would be a good solution for creating one-time solution on a task. But to create solution that can be reuse/deploy/distribute will require a more sophisticated workflow. It's both challenging and exciting!

To enable such experience, one of the challenges is how to construct a workflow that can be used to incremental editing/improving a workspace or project, rather than a single file. I don't have a very clear answer for that question now, but feel free to provide any thought on it.

[dazinator]

To enable such experience, one of the challenges is how to construct a workflow that can be used to incremental editing/improving a workspace or project, rather than a single file. I don't have a very clear answer for that question now, but feel free to provide any thought on it.

I was thinking at a very high level, I'd want to structure something like a dev team, consisting of:

• Product Owner Role (user proxy agent)
  • initiates work by providing a "user story"
  • is asked to clarify any requirements
• Developer (assistant agent)
  • planning phase
    • tries to break down user story into set of actionable tasks
    • if has any questions around the requirements, asks the product owner for clarification
  • development phase
    • iterate on the tasks until the code passes QA
      • e.g might be a task to create the new dotnet project, then add specific classes and tests that implement the required functionality.
    • let QA know when something is completed for testing.
    • if QA reports any issues then ask any clarifying questions to QA and then plan a task to fix it.
• QA (assistant)
  • take the output from developer assistant and try to run it.
  • if the code passes QA checks then TERMINATE
    • else report any issues back to Developer assistant.

Something like that.

I'm order to try to eliminate some of the complexity, I thought it might be a good idea if this team was always focused on producing an entirely new dotnet project - I.e so it doesn't have to understand any pre-existing code base. I'm not sure how much this helps as I guess if the developer agent has to iterate on its own output then to some degree it has to be able to "understand" the output it has produced in a prior iteration.

I'm completely knew to all this, and I have no feel for whats actually possible yet - so this was going to be my thesis for getting stuck into and learning about this project and just what is possible right now.

[dazinator]

Sorry I have no idea about the workspace / single file issue. I thought I had seen another open source project that is able to iterate on a code base containing multiple files, perhaps it was AutoGPT.. but I can't remember :-(

[twobob]

Sorry I have no idea about the workspace / single file issue. I thought I had seen another open source project that is able to iterate on a code base containing multiple files, perhaps it was AutoGPT.. but I can't remember :-(

chatdev. possibly @dazinator

[JunkBoy76]

(sorry im new to all this so sorry if i come across as an idiot for asking this) could you add support for local llm's heres a template that im using that works for me

config_list = [ { "api_type": "open_ai", "api_base": "https://yyyyyyyyyy-5001.proxy.runpod.net/v1", "api_key": "sk-1111111111111111111111111111111111111111" } ]

[colombod]

.NET Interactive can also run a “csproj” via a Project Kernel. That is something Try .NET does it and we could expand that to fit the scenario emitting a reusable le project / solution

Dr Diego Colombo (he/him) Principal software engineer .NET Interactive https://github.com/dotnet/interactive

---

From: JunkBoy76 @.> Sent: Saturday, October 28, 2023 3:58:22 AM To: microsoft/autogen @.> Cc: Comment @.***> Subject: Re: [microsoft/autogen] Bring AutoGen to dotnet? (Issue #48)

could you add support for local llm's heres a template that im using that works for me

config_list = [ { "api_type": "open_ai", "api_base": "https://yyyyyyyyyy-5001.proxy.runpod.net/v1", "api_key": "sk-1111111111111111111111111111111111111111" } ]

— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/autogen/issues/48#issuecomment-1783688424 or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAC3WBHTQNMNMC725SILSFDYBR7F5BFKMF2HI4TJMJ2XIZLTSSBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVI3DAMZUGYYTGOBXGCSG4YLNMWUWQYLTL5WGCYTFNSWHG5LCNJSWG5C7OR4XAZNMJFZXG5LFINXW23LFNZ2KM5DPOBUWG44TQKSHI6LQMWVHEZLQN5ZWS5DPOJ42K5TBNR2WLKJWHAYDCMRQGA3TDAVEOR4XAZNFNFZXG5LFUV3GC3DVMWVDCOJRHE3DONRWGQ3YFJDUPFYGLJLMMFRGK3FFOZQWY5LFVI3DAMZUGYYTGOBXGCTXI4TJM5TWK4VGMNZGKYLUMU. You are receiving this email because you commented on the thread.

Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[Ryangr0]

I just don't see any future for multiple codebases unless there is first class support. Things are always going to end up missing, or different, maybe even architecturally or conceptually.

[luisquintanilla]

Looks like Qdrant has built support for AutoGen. It'd be interesting to test out the integration in .NET.

https://qdrant.tech/documentation/integrations/autogen/

[erhan0]

Hi @LittleLittleCloud ! Is this still being worked on? If so, how are you keeping up to date with the broader Python counterpart, including beta features?

[LittleLittleCloud]

Which beta feature are you talking about 😀

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Erhan Kartaltepe @.> Sent: Wednesday, November 29, 2023 4:01:35 AM To: microsoft/autogen @.> Cc: Mention @.>; Author @.>; Comment @.>; Assign @.> Subject: Re: [microsoft/autogen] Bring AutoGen to dotnet? (Issue #48)

Hi @LittleLittleCloudhttps://github.com/LittleLittleCloud ! Is this still being worked on? If so, how are you keeping up to date with the broader Python counterpart, including beta features?

— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/autogen/issues/48#issuecomment-1830632473 or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEAYLOXS4LRMNCEP6TZZWS3YGY7KBBFKMF2HI4TJMJ2XIZLTSSBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVI3DAMZUGYYTGOBXGCSG4YLNMWUWQYLTL5WGCYTFNSWHG5LCNJSWG5C7OR4XAZNMJFZXG5LFINXW23LFNZ2KM5DPOBUWG44TQKSHI6LQMWVHEZLQN5ZWS5DPOJ42K5TBNR2WLKJWHAYDCMRQGA3TDAVEOR4XAZNFNFZXG5LFUV3GC3DVMWVDCOJRHE3DONRWGQ3YFJDUPFYGLJLMMFRGK3FFOZQWY5LFVI3DAMZUGYYTGOBXGCTXI4TJM5TWK4VGMNZGKYLUMU. You are receiving this email because you were mentioned.

Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[bitnom]

I just don't see any future for multiple codebases unless there is first class support. Things are always going to end up missing, or different, maybe even architecturally or conceptually.

Does this mean you're in favor of merging #924 ? My initial thoughts:

• It's difficult for me to imagine it not being disruptive in terms of issues and PRs.
• Every dotnet issue and PR will need to be tagged as such.
• We will likely end up with many additional issues which go unresolved for long periods of time unless the port has parity with the Python module.
• Installing the Python module direct from the repo will pull the dotnet port into the project each time.
• My IDE will index symbols from the port (Maybe this can be handled).
• Is there a nexus between the main Python module and the dotnet port? Do they interop in some way?
  • Note: Currently, if I wanted to made use of something in dotnet, I would probably use pythonnet or similar.
  • Might it be easier for future humans to deal with wrapping the existing module for use in dotnet?
    • IronPython comes to mind, though I have never used it.
    • I think there are other ways to wrap a Python module in dotnet as well. The laziest way would probably be to bundle python.
  • A path to automated transpile would be cool.

[colombod]

• Is there a nexus between the main Python module and the dotnet port? Do they interop in some way?

one of the things we are pondering is about using the work in .NET Interactive as a mean of interoperability.

[Karl-AA]

Great to see someone is working on getting AutoGen in .Net!

I also want to point people to https://github.com/SciSharp/BotSharp Which is a comparable multi-agent llm framework. Check it out!

[MovGP0]

Porting the source code of AutoGen to .NET/TypeScript/Java/Rust/etc. ist exactly the kind of work, which a system like AutoGen should be able to do.