Add .NET self-learning architect agent

[behl1anmol]

Pull Request Checklist

• I have read and followed the CONTRIBUTING.md guidelines.
• I have read and followed the Guidance for submissions involving paid services.
• My contribution adds a new instruction, prompt, agent, skill, or workflow file in the correct directory.
• The file follows the required naming convention.
• The content is clearly structured and follows the example format.
• I have tested my instructions, prompt, agent, skill, or workflow with GitHub Copilot.
• I have run npm start and verified that README.md is up to date.

Description

New agent: dotnet-self-learning-architect

This contribution adds a principal-level .NET architect agent with strong execution and governance guidance, including:

• expertise across .NET 6+, C#, ASP.NET Core Web APIs, EF Core/LINQ, authn/authz, Docker/Kubernetes, Azure services, SQL, and architecture patterns.
• rationale-first behavior (no fabrication), explicit ambiguity handling, and concise progress reporting.
• delegation strategy that chooses between parallel subagents and orchestrated team mode based on dependency/risk analysis.
• mandatory user confirmation before orchestration-team mode.
• self-learning behavior with .github/Lessons and .github/Memories templates.
• required subagent completion output fields: LessonsSuggested, MemoriesSuggested, and ReasoningSummary.

Documentation was regenerated to include the new agent listing in README.agents.md.

Type of Contribution

• New instruction file.
• New prompt file.
• New agent file.
• New plugin.
• New skill file.
• New agentic workflow.
• Update to existing instruction, prompt, agent, plugin, skill, or workflow.
• Other (please specify):

Additional Notes

By submitting this pull request, I confirm that my contribution abides by the Code of Conduct and will be licensed under the MIT License.

[aaronpowell]

I'm not sure I really understand this agent over the default agents combined with the .NET skills which can be installed via the plugin marketplace.

It refers to .NET 6, which has been EOL for nearly 18 months, and other than that there's not really anything .NET (or other) language/runtime specific in here.

Also, Copilot has memory built in so there's not a large need to define a memory system in an agent.

Have you got some examples of this agent in use and the outcomes it improves upon?

[behl1anmol]

I'm not sure I really understand this agent over the default agents combined with the .NET skills which can be installed via the plugin marketplace.

It refers to .NET 6, which has been EOL for nearly 18 months, and other than that there's not really anything .NET (or other) language/runtime specific in here.

Also, Copilot has memory built in so there's not a large need to define a memory system in an agent.

Have you got some examples of this agent in use and the outcomes it improves upon?

Hi @aaronpowell, thank you for the detailed feedback — I really appreciate you taking the time to review this carefully.

You're absolutely right about .NET 6 — I've already updated the agent to target .NET 8+.

On the broader question of how this differs from the default agents combined with .NET skills: the intent here is not to duplicate those capabilities, but to introduce a self-learning execution pattern on top of them — specifically designed for long-running, architecture-heavy work on a real codebase.

The two key additions this agent provides are:

Lessons
When the agent makes a mistake, the context of what went wrong and how it was fixed is typically scoped to the current chat session and may get summarised or lost due to limited context windows. Lessons are stored directly in the workspace, making them persistent and accessible across sessions — helping the agent avoid repeating the same mistakes on the same codebase.

Memories
While Copilot's built-in memory is a great general-purpose feature, the intent here is for the agent to build a durable, workspace-scoped understanding of key architectural decisions and patterns specific to the project. This is intentionally complementary rather than competing with built-in memory.

Together, these shift the agent from having a volatile, session-scoped understanding of a codebase to a more permanent, cumulative one — similar to how a developer naturally builds familiarity with a project over time.

I've been using this pattern in my own work and found it effective in reducing repeated errors and improving continuity across sessions. An example of how lessons and memories are structured in practice can be found here: MediatorLite commit

I am open to suggestions on how to better scope or present this so it's clearly additive to the existing .NET skills.

[aaronpowell]

Lessons When the agent makes a mistake, the context of what went wrong and how it was fixed is typically scoped to the current chat session and may get summarised or lost due to limited context windows. Lessons are stored directly in the workspace, making them persistent and accessible across sessions — helping the agent avoid repeating the same mistakes on the same codebase.

Memories While Copilot's built-in memory is a great general-purpose feature, the intent here is for the agent to build a durable, workspace-scoped understanding of key architectural decisions and patterns specific to the project. This is intentionally complementary rather than competing with built-in memory.

Together, these shift the agent from having a volatile, session-scoped understanding of a codebase to a more permanent, cumulative one — similar to how a developer naturally builds familiarity with a project over time.

How does it handle growth over time? Say after 6 months, 12, longer? the agent is always adding but does it remove? What if patterns change or fixes are adjusted since the agent created its memory? Does it not run the risk of repeating invalid patterns?

[behl1anmol]

Lessons When the agent makes a mistake, the context of what went wrong and how it was fixed is typically scoped to the current chat session and may get summarised or lost due to limited context windows. Lessons are stored directly in the workspace, making them persistent and accessible across sessions — helping the agent avoid repeating the same mistakes on the same codebase.

Memories While Copilot's built-in memory is a great general-purpose feature, the intent here is for the agent to build a durable, workspace-scoped understanding of key architectural decisions and patterns specific to the project. This is intentionally complementary rather than competing with built-in memory.

Together, these shift the agent from having a volatile, session-scoped understanding of a codebase to a more permanent, cumulative one — similar to how a developer naturally builds familiarity with a project over time.

How does it handle growth over time? Say after 6 months, 12, longer? the agent is always adding but does it remove? What if patterns change or fixes are adjusted since the agent created its memory? Does it not run the risk of repeating invalid patterns?

Hi @aaronpowell,

Thank you for the questions — they directly address the long-term durability of this pattern.

Repeating Invalid Patterns

In practice, I've observed the agent actively revising lessons and memories as it progresses through different tasks — it doesn't just append blindly. To make this behaviour explicit and enforceable, I've added a Learning Governance section to the agent file (see commit b307f0c) which mandates:

• Pre-Write Dedupe Check — before creating any new lesson or memory, the agent must search for similar existing patterns and update them instead of creating duplicates.
• Conflict Resolution — if new evidence contradicts an existing active pattern, the older one must be marked deprecated or blocked. Two conflicting active patterns are not permitted to coexist.
• Safety Gate — patterns marked blocked can never be applied or recommended without explicit user confirmation and validation evidence.
• Versioned Patterns — every lesson and memory carries a PatternId, PatternVersion, and Status, making it clear which version of a pattern is current and what it supersedes.

Handling Growth Over Time

You raise a fair point about unbounded growth over 6, 12+ months. My current thinking is to leave growth management in the hands of the user, giving them flexibility to prune, archive, or restructure lessons and memories based on their own project lifecycle. However, I agree that adding explicit expiration and archival guidance into the governance section would make this more durable out of the box. I am happy to add:

• An ExpiresAfter or ReviewBy metadata field on lessons and memories.
• A governance rule instructing the agent to flag stale patterns (e.g., not validated within N months) for user review or archival.

I will add these if you feel it strengthens the agent sufficiently for inclusion.