Reorganize samples

[JimDaly]

This PR implements the changes proposed in Agents SDK Sample Plan doc

Companion PR makes changes to paths in the docs: https://github.com/MicrosoftDocs/businessapps-copilot-docs-pr/pull/979

This also adds the Python samples.

[tracyboehrer]

• If we are going to keep multi-turn-prompt it needs to indicate "compat" since it is an ActivityHandler based agent. We need to be clearer that ActivityHandler based agents are not the recommended path. DotNet will have some too, but more related to a "tutorial" on migration from BF SDK.
• implement-semantic-kernel is not consistent with integrate-langchain. Also, too generic. There could be other SK or langChain samples. How about semantickernel-weatheragent and langchain-weatheragent.
  • That way when we add others they are grouped.
• RetrievalBot is inconsistent: Case and "bot". But... it's more to that in the project and probably out of scope for this PR.
• We will need to add launchSettings.json to .gitignore (preferrably) or remove those files from the PR.
• I assume the samples in the old locations will be removed in the same PR.

[tracyboehrer]

I wonder if the "compat" samples should be in a different folder? i.e., Not samples. They exist to demonstrate migration, and that folder can have a README with guidance. Not hard to imagine these will go away some day.

In BF-land, when BF SDK v4 came out, there was a Migration folder created, with a MigrationV3V4 under that. I don't think we need that folder depth. Maybe.

[JimDaly]

@tracyboeher

implement-semantic-kernel is not consistent with integrate-langchain. Also, too generic. There could be other SK or langChain samples. How about semantickernel-weatheragent and langchain-weatheragent.

• That way when we add others they are grouped.

These names were available for discussion earlier in Agents SDK Sample Plan , but we can revisit them.

I know nothing about semantic kernel or langchain. But felt that the goal of these samples wasn't about how to create a weather agent. I don't think these should have names involving 'weather agent' unless that is the goal of the sample. My understanding is that the weather agent is just an implementation detail to demonstrate something. But, I could be wrong.

Only after reading the README could I come to understand that the goal of these samples is to demonstrate this capability that has different names for each language. That is the problem I'm trying to address.

Are these known as 'orchestrators'?
How about 'implement-orchestrator'?

[tracyboehrer]

I know nothing about semantic kernel or langchain. But felt that the goal of these samples wasn't about how to create a weather agent. I don't think these should have names involving 'weather agent' unless that is the goal of the sample. My understanding is that the weather agent is just an implementation detail to demonstrate something. But, I could be wrong.

You are correct. "WeatherAgent" is just used to demonstrate. "SemanticKernel" is what we are showing. But... that likely won't be the only SK thing we demonstrate. What then? implement-sematic-kernel2?

Furthermore, "streaming" is what we wanted to show, and we called it azure-ai-streaming. When we want to show CopilotStudio it's "copilotstudio-*.

[JimDaly]

@tracyboehrer

You are correct. "WeatherAgent" is just used to demonstrate. "SemanticKernel" is what we are showing. But... that likely won't be the only SK thing we demonstrate. What then? implement-sematic-kernel2?

I expect that this existing sample is showing the basics of semantic kernel. Other samples will provide more complex/advanced capabilities. At that time, I think we could call them sk-<goal> where the <goal> reflects the key thing the sample teaches beyond the implement-sematic-kernel sample.

If you are recommending that we use semantic-kernel-implement as the folder name instead. I'm fine with that. I just didn't want it to be named weather-agent. What do you want to name the folder?

[tracyboehrer]

@tracyboehrer

You are correct. "WeatherAgent" is just used to demonstrate. "SemanticKernel" is what we are showing. But... that likely won't be the only SK thing we demonstrate. What then? implement-sematic-kernel2?

I expect that this existing sample is showing the basics of semantic kernel. Other samples will provide more complex/advanced capabilities. At that time, I think we could call them sk-<goal> where the <goal> reflects the key thing the sample teaches beyond the implement-sematic-kernel sample.

If you are recommending that we use semantic-kernel-implement as the folder name instead. I'm fine with that. I just didn't want it to be named weather-agent. What do you want to name the folder?

I'm opposed to "implement", or "integrate". If I were to give a generic name I would say something like "sematickernel-multiturn".

Do note you can't just change the folder name for DotNet projects. The csproj and then namespace would have to change as well. Some minor changes to README's because usually the name is used in there too.

[JimDaly]

@tracyboehrer

Do note you can't just change the folder name for DotNet projects. The csproj and then namespace would have to change as well. Some minor changes to README's because usually the name is used in there too.

Got it Ask ChatGPT: How important is it that the name of the folder that contains a .NET project have the same name as the project?

Not technically required, but expected. The WeatherAgent project builds just fine within the quickstart folder.
I'll make the changes.

[JimDaly]

@tracyboehrer

I wonder if the "compat" samples should be in a different folder? i.e., Not samples. They exist to demonstrate migration, and that folder can have a README with guidance. Not hard to imagine these will go away some day.

In BF-land, when BF SDK v4 came out, there was a Migration folder created, with a MigrationV3V4 under that. I don't think we need that folder depth. Maybe.

There is only one JavaScript sample in the compat folder. See https://github.com/microsoft/Agents/tree/main/samples/compat. The README for that sample says nothing about demonstrating migration.

[tracyboehrer]

@tracyboehrer

I wonder if the "compat" samples should be in a different folder? i.e., Not samples. They exist to demonstrate migration, and that folder can have a README with guidance. Not hard to imagine these will go away some day.
In BF-land, when BF SDK v4 came out, there was a Migration folder created, with a MigrationV3V4 under that. I don't think we need that folder depth. Maybe.

There is only one JavaScript sample in the compat folder. See https://github.com/microsoft/Agents/tree/main/samples/compat. The README for that sample says nothing about demonstrating migration.

Leave it as what this PR does for now. The broader issue is we didn't have a goal of providing compat samples, except in the context of migration. i.e., All samples should be AgentApplication-based otherwise.

This will have to be a follow up discussion on the engineering team about what we want to do around this.

[JimDaly]

@rodrigobr-msft
I see you added the python samples. What is missing is some of the name changes described in Agents SDK Sample Plan doc

These changes are:

• empty-agent => quickstart: The emphasis is on that this is the minimum sample to get started with quickly. Reader doesn't necessarily know what an 'empty agent' is, but they will discover when they locate this sample.
• weather-agent => The sample uses a weather agent scenario to teach something. No one wants to learn how to create a weather agent per se... we use this to demonstrate introduce using Semantic Kernel with .NET or LangChain with JavaScript. What about Python? I can't tell from the code, but the sample name should focus on that rather than on 'weather-agent'. For .NET the recommended name is semantic-kernel-multiturn, so for Javascript we are also using langchain-multiturn. What should we use for Python?
• azureai-streaming-poem-agent => azureai-streaming Again. the fact that it is a poem agent isn't the focus. We can have a shorter, more focused name.

Make sense?

[tracyboehrer]

@JimDaly NodeJS should also have the quickstart project. It can be referenced from the doc for convenience. Is there a reason it's not currently in the nodejs tree?

[JimDaly]

@JimDaly NodeJS should also have the quickstart project. It can be referenced from the doc for convenience. Is there a reason it's not currently in the nodejs tree?

@tracyboehrer
Thanks for catching this. I added them in this commit: add empty-agent files to quickstart folder

[rodrigobr-msft]

• weather-agent => The sample uses a weather agent scenario to teach something. No one wants to learn how to create a weather agent per se... we use this to demonstrate introduce using Semantic Kernel with .NET or LangChain with JavaScript. What about Python? I can't tell from the code, but the sample name should focus on that rather than on 'weather-agent'. For .NET the recommended name is semantic-kernel-multiturn, so for Javascript we are also using langchain-multiturn. What should we use for Python?

We can use semantic-kernel-multiturn, as the Python sample has been updated to use Semantic Kernel.