Documentation is grossly outdated and we don't even have proper demo/explanation of the github flow, nor the abstractions that surfaced while building this.

I suggest we work on documenting:

• How to run this locally
• Reasoning and rationally behind the project and the AiAgents
• Event flow for the GH dev agents

biostatisticians spend a massive among of time gathering clinical trials data, statistics to figure out where a given drug would be best suits based in race, body condition; sick, pregnant, overweight. Data are typically extracted from following links that is public and links to FDA authorities:

Sample data:

Ask: Ideally, a model that chooses the personas that are best for the job. If they for example have 50 agents that the job can pick from, the first initial task is to select the best 5-10 agents to solve the given task; ex. Dev, project manager, approver, writer. This is an interesting approach.

Customers are building their own OpenAI portal experience that uses; Phi, dall-e, gpt-4 vision for internal services.
They want to avoid as much as possible that employees do not leak confidential data via openai but should default to their internal website. Dall-e is leading the charge and 2-3 partners are driving this with the assistance of PG, AI CSA's and GBB (AI and App Inno).
Awaiting next step and round of funding.

     at Azure.Core.HttpPipelineExtensions.ProcessMessageAsync(HttpPipeline pipeline, HttpMessage message, RequestContext requestContext, CancellationToken cancellationToken)
     at Azure.AI.OpenAI.OpenAIClient.GetEmbeddingsAsync(EmbeddingsOptions embeddingsOptions, CancellationToken cancellationToken)
     at Microsoft.SemanticKernel.Connectors.OpenAI.ClientCore.RunRequestAsync[T](Func`1 request)
     --- End of inner exception stack trace ---
     at Microsoft.SemanticKernel.Connectors.OpenAI.ClientCore.RunRequestAsync[T](Func`1 request)
     at Microsoft.SemanticKernel.Connectors.OpenAI.ClientCore.GetEmbeddingsAsync(IList`1 data, Kernel kernel, CancellationToken cancellationToken)
     at Microsoft.SemanticKernel.Embeddings.EmbeddingGenerationExtensions.GenerateEmbeddingAsync[TValue,TEmbedding](IEmbeddingGenerationService`2 generator, TValue value, Kernel kernel, CancellationToken cancellationToken)
     at Microsoft.SemanticKernel.Memory.SemanticTextMemory.SearchAsync(String collection, String query, Int32 limit, Double minRelevanceScore, Boolean withEmbeddings, Kernel kernel, CancellationToken cancellationToken)+MoveNext()
     at Microsoft.SemanticKernel.Memory.SemanticTextMemory.SearchAsync(String collection, String query, Int32 limit, Double minRelevanceScore, Boolean withEmbeddings, Kernel kernel, CancellationToken cancellationToken)+System.Threading.Tasks.Sources.IValueTaskSource<System.Boolean>.GetResult()

2
at Microsoft.AI.Agents.Orleans.AiAgent`1.AddKnowledge(String instruction, String index, KernelArguments arguments) in /Users/ryan/src/project-oagents/src/Microsoft.AI.Agents.Orleans/AiAgent.cs:line 68
at Microsoft.AI.DevTeam.ProductManager.CreateReadme(String ask) in /Users/ryan/src/project-oagents/samples/gh-flow/src/Microsoft.AI.DevTeam/Agents/ProductManager/ProductManager.cs:line 65
Microsoft.AI.DevTeam.ProductManager: Error: Error creating readme

Microsoft.SemanticKernel.HttpOperationException: This model's maximum context length is 4095 tokens, however you requested 5730 tokens (5730 in your prompt; 0 for the completion). Please reduce your prompt; or completion length.
Status: 400 (model_error)

Content:
{
"error": {
"message": "This model's maximum context length is 4095 tokens, however you requested 5730 tokens (5730 in your prompt; 0 for the completion). Please reduce your prompt; or completion length.",
"type": "invalid_request_error",
"param": null,
"code": null
}
}

Error is in the logs but what the bot posts in issues isn't helpful: "Sorry, I got tired, can you try again please?"

We want to add .NET aspire to get service - local injection abstractions and open telemetry dashboards.
We also want to attempt to show an agent implementation in python consuming events emitted by an Orleans agent or vice versa

enable the dev agent samples to work against this repo.

Shared state between agents working on a task.

Justification

I need to configure pipelines for Marketing sample

Duration (hours)

2

The repository often mentions "GitHub Flow" or gh-flow, which is misleading, because there already is an official GitHub Flow in the industry, which is a common branching pattern. It was misleading to me and might also be to others. I'd suggest finding a new name for it.

Suggestion: "Developer Agents Workflow on GitHub" (sounds less GitHub-official, is more descriptive)

Is a Project Manager and Software Engineer, I find the flow of opening dozens of GitHub Issues for the single tasks of the agent very unintuitive and confusing. Especially, as it does not reflect what humans would do. In addition, I think it's weird that the agents post the code they want to generate as comments to a GitHub issue instead of opening a Pull Request, where code can be properly discussed. Lastly, closing issues before the actual work on them is done also looks like a bad practice to me.

Here is, how an ideal flow would look like to me:

1. Human Project Manager opens a GitHub issue with a description of what to achieve
2. Human Project Manager labels the issue with dev-agents label, to trigger the AI work
3. First Agents starts the work and describes the project plan in Markdown as a comment to the issue
4. Human Project Manager can give feedback and iterate on it in the comments.
5. Once satisfied, the issue get labeled differently (e.g. coding-plan), which triggers another Agent to plan the coding work
6. An Agent generates the step-by-step plan (To Do List) and posts it as a comment to the issue
7. Human Project Manager can give feedback and iterate on it in the comments.
8. Once satisfied, the issue gets labeled again (e.g. start-coding), which triggers another Agent to start the coding work
9. An Agent creates a new branch, commits code and creates a Pull Request, with the code changes and links the PR to the issue
10. Human Developer can give feedback on the code and iterate on it in the PR comment.
11. Once satisfied, the PR gets merged and the Issue automatically gets closed

Am I missing anything, why the flow is not like this but happens across so many issues?

Am I misunderstanding anything, which makes my suggested flow not possible?

Some initial thoughts on adding memories.

Types of memories

I think we want the skills to be able to take advantage of multiple types of memories. This will allow for specialization, and for adding new types in the future, while keeping the collections topic focused and clean.

Memory collection for the Repo

Scope: per repository
This collection would include

• all the files in the repo, ideally chunked according to their type/structure
• Code Explanations for all the files in the repo, produced by the model
• Issues from the repo
• a "repo map" of project structure in natural language or maybe we find/invent a format

Shared Memory across the Skills

Scope: per repository (possibly per v-team - what if teams work on multiple repos?)
This collection would be used to help coordinate actions across the v-team of AI skills:

• including all instructions received from the human collaborators
• conversation history
• identity and specializations of each skill in the V-team
• role-assignments/what each member of the team is working on
• for shared systems, (if the plan specifies a shared component) then key details of the shared system (eg config var names, directory paths, class names, etc)
• think of this as shared memory for all the skills, we could actually make a record that stores important shared state in the vectored and is retrieved as needed by each skill

Working memory within a single skill

Scope: per repository (possibly per v-team - what if teams work on multiple repos?)
This collection would implement the working memory for an individual skill (or skill group) and include the original prompt and conversation history for that skill, as well as any data on the files that the skill may have modified or generated.

Specialization Memories

Scope: Any
These would be special read-only curated collections designed to give an AI agent a set of memories around some specialized knowledge. Think of in the Matrix when Neo says "Now I know KungFu!". They would be wired up through configuration or code depending on the needs of the skill.
eg:

• WAF framework, 12 Factor, etc for Azure architecture
• .NET learning content, .NET best practices, r9 SDK etc for .NET specialists
• ^^^^ for each programming language...
• CVEs and MITRE, security coding standards, examples of security fix before and after etc for security specialist
• patterns and practices for performance improvement for specific languages.
  Each of these types of memories should end up being a long running shared service with its own nuget etc that can just be included with a "using". They can improve over time as new documentation or code becomes available.

Implementation

Some thoughts on how to do the implementation:

• let's make each type of memory a separate project but stick to an API that is compatible with the SK MemoryStore
• while prompt templating {{recalll}} can be useful, more likely we will need a pattern that is specific to each skill for bringing in the memories at the right spot using the vector search.
• Each skill would likely apply an hierarchy to the memories, with an implied flow:
• 1. Prompt assembly
• 2. Shared Memory for details relevant to the prompt
• 3. Working Memory details relevant to the prompt
• 4. Specializations collections that are relevant to the prompt

We would need to allocate a certain amount of the token budget to each memory type, but for instance if vector search of working memory doesn't yield relevant results we might give some of its budget to the Specializations.

We should probably build the memory initialization as a background service that starts and does a warm-up when the app starts.

Architect that works on the high level plan, then a dev lead per subtask, which orchestrates developer/tester

#73
failing on unchanged files:
Run azd provision `
Error: flag needs an argument: --environment
Error: Process completed with exit code 1.

Tracking the next things we could add to the marketing app

• Make it multi-user
• Create a boilerplate project
• Nuget for AI Agent for Boilerplate
• Readme with getting started
• azd for local debugging
• Docker support
• Delete the controller and the Ask
• Test project
• Pipeline

At the moment, the repo only some (hard to read/understand) text about the motivation of the repository and the rough flow. What I think is missing is detail around

1. How it was built (Semantic Kernel, C#, which Web Services and how many) = Architecture overview
2. Quick Intro to "What are Agents" and how they work
3. Description of the different Agents that this repo uses and how they operate