Skip to content

Instantly share code, notes, and snippets.

@davidortinau

davidortinau/agent-service-research.md

Last active March 20, 2026 16:57
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save davidortinau/59c5bb2a29f190c7ab3731ba628daece to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save davidortinau/59c5bb2a29f190c7ab3731ba628daece to your computer and use it in GitHub Desktop.
Download ZIP
Mission Brief: .NET × Foundry — Customer Clarity Sprint
Raw
agent-service-research.md

Research: Foundry Agent Service — What Is It and What's the .NET Migration Path?

Context: David Ortinau walked through the Foundry Agent Service GA announcement and docs as a .NET developer already using Agent Framework + M.E.AI + Foundry model endpoints. This documents what we found.

The Setup

A .NET developer today using:

  • Microsoft Agent Framework for agent orchestration
  • Microsoft.Extensions.AI for model abstraction and tool integration
  • Foundry/Azure endpoints (ai.azure.com) for model inference (GPT-4o, Whisper, etc.)
  • Self-hosted on ASP.NET Core / Aspire / ACA

This is the stack we want people on. The question: what does Foundry Agent Service add, and how do you get there?

What Foundry Agent Service Actually Is

Agent Service is a separate product layer that sits on top of Foundry's model hosting. It is NOT an upgrade to your existing Foundry model deployments — it's an additional managed runtime you opt into.

Three agent types (overview):

Type What it is Code required Status
Prompt agents Defined entirely through config — instructions, model, tools. Foundry owns orchestration. No GA
Workflow agents Multi-step orchestration via visual builder or YAML. No (YAML optional) Preview
Hosted agents Your containerized code deployed to Foundry's managed runtime. Yes Preview

What Agent Service adds over raw model access:

  • Managed agent hosting with autoscaling
  • Built-in tracing and observability (Application Insights)
  • Evaluation pipelines with continuous production monitoring (evals GA)
  • Enterprise security: private networking, Entra RBAC, content filters
  • MCP tool connections with managed auth (key-based, Entra, OAuth passthrough)
  • Voice Live: real-time speech-to-speech (preview)
  • Publishing agents to M365/Teams and Entra Agent Registry
  • Conversation state management

What it does NOT replace:

  • Your model deployments (those stay as-is)
  • Your Agent Framework orchestration logic (you keep it for hosted agents)
  • M.E.AI abstractions (still the foundation)

The GA Blog Post Confusion

Source: Foundry Agent Service GA announcement (March 2026)

The blog says: "If you're building with the Responses API today, migrating to Foundry is minimal code changes."

This is confusing because:

  1. It targets developers on api.openai.com (direct OpenAI), not developers already on Foundry
  2. If you're already on Foundry calling model endpoints, you're NOT "on the Responses API" — you're on the chat completions API
  3. The blog conflates "using Foundry" (model hosting) with "using Agent Service" (managed agent runtime)
  4. A developer already inside Foundry reading this blog cannot tell if they need to do something

Also notable: Every code sample in the GA blog is Python. Zero C#. This is the Foundry team's flagship announcement and .NET is invisible.

Docs Landscape

Doc URL C#? Useful for migration?
Agent Service overview link N/A Conceptual understanding
Quickstart (get-started-code) link ✅ C# tabs Builds from scratch, not migration
Agent Framework → Foundry provider link ✅ C# code Closest to migration path — shows Agent Framework connecting to Agent Service
Hosted agents concept link ✅ Listed in framework table Deploy-your-container model, preview
Hosted agents quickstart link ⚠️ VS Code ext supports C#, but azd CLI is Python-only Step-by-step deploy, but Python-first
Workshop (75 min) link ❌ Python only Builds from scratch
Classic C# quickstart samples link ✅ Samples, not migration guide

Two Migration Paths (Neither Cleanly Documented)

Path A: Hosted Agent (Preview) — Most Natural

This is the "bring your own code" path. You containerize your existing Agent Framework app and deploy it to Foundry's managed runtime.

What you'd do:

  1. Add NuGet packages: Azure.AI.AgentServer.Core, Azure.AI.AgentServer.AgentFramework
  2. Wrap your Agent Framework code with the hosting adapter
  3. The adapter exposes your agent as an HTTP service (Responses API compatible)
  4. Containerize (Dockerfile)
  5. Deploy via VS Code Foundry extension (supports C#) or azd up (Python-first)
  6. Foundry manages scaling, identity, conversation state, and the API surface

What you gain:

  • Managed hosting (no ACA/App Service to manage)
  • Foundry tracing and eval pipelines
  • MCP auth management
  • Publishable to M365/Teams
  • Conversation state management

What you give up:

  • Direct control over hosting infrastructure
  • Aspire integration (unclear how this works with hosted agents)
  • Possibly: networking flexibility (no private networking for hosted agents during preview)

Current status:

  • Preview — not production-ready
  • C# is listed as supported for Agent Framework hosted agents
  • But the tooling (azd CLI quickstart) only shows Python
  • The VS Code extension supports C# scaffolding for new projects
  • No doc exists for migrating an existing Agent Framework app — only for creating new ones

Path B: Prompt Agent — Requires Rewrite

This path means redefining your agent as a Foundry-managed prompt agent, where Foundry owns all orchestration.

What you'd do:

  1. Use Azure.AI.Projects NuGet package
  2. Create agent via AIProjectClient.Agents.CreateVersion()
  3. Register your tools as MCP servers or function calls on the Foundry side
  4. Interact via the Responses API through project.GetOpenAIClient()
  5. Give up Agent Framework orchestration entirely — Foundry handles it

What you gain:

  • Fully managed, no container to build
  • All Agent Service features (GA, not preview)
  • Simplest operational model

What you give up:

  • All Agent Framework orchestration logic
  • Multi-agent patterns you've built
  • M.E.AI middleware, filters, and extensibility
  • Control over how tools are invoked and composed
  • This is not a migration — it's a rebuild

The Gap (Key Finding)

There is no documentation that addresses this scenario:

"I have an existing .NET app using Agent Framework + M.E.AI calling Foundry model endpoints, self-hosted on ASP.NET/Aspire/ACA. How do I deploy this to Foundry Agent Service?"

The pieces exist across 4-5 different doc pages, but no one has stitched them into a coherent migration story. The closest doc is the Agent Framework Foundry provider page, which shows Agent Framework connecting to Agent Service — but it starts from scratch, not from an existing app.

This is the single most natural upgrade path for the developer we want to exist — a .NET developer already on our recommended stack — and it has no documented on-ramp.

Key Questions This Raises for the Mission Brief

  1. Is Hosted Agents the intended landing zone for Agent Framework apps? Or is there a different deployment model we should expect? The preview status creates uncertainty.

  2. What happens to Aspire? If you're using Aspire for local dev and orchestration today, how does that compose with Foundry Agent Service hosting? Is Aspire complementary, or does Foundry replace it?

  3. Is the Agent Framework → Agent Service handoff actually seamless? Has anyone on the .NET team or customer base tried it end-to-end? The hosting adapter (Azure.AI.AgentServer.AgentFramework) exists as a NuGet package, but we found no walkthrough.

  4. Why is the GA blog Python-only? Is this a content gap, or does it reflect that C# isn't ready? The quickstart has C# tabs, so the SDK exists — but the flagship narrative excludes .NET.

  5. Who should we ask? Glenn Condron is working on Foundry templates and DX from the inside. Jeff Hollan owns Agent Service. The answer to "what's the .NET → Agent Service migration story" likely lives between them.

This research was conducted March 20, 2026 by walking the docs and GA blog as a .NET developer would. The confusion documented here is the actual developer experience.

Raw
foundry-recon.md

Recon: Foundry Contacts, Meetings & Projects for .NET Platform and Tooling

Context: Intelligence gathered to support the .NET × Foundry Customer Clarity Sprint. This covers who to talk to, what meetings to request invitations to, and what Foundry-side projects to be aware of — all on the Foundry side of the house, not our own .NET meetings.

Note: Our .NET team (Jeremy Likness, Leslie Richardson, Art Leonard, Sayed Hashimi, Steve Carroll, Gaurav Seth, Tim Heuer) already owns Microsoft.Extensions.AI and the MCP SDK for .NET. This document focuses on the Foundry counterparts we need to connect with.

Key People on the Foundry Side

Jeff Hollan — Partner Director of Product Management, Agent Services

  • Reports to: Amanda Silver
  • Owns: Foundry Agent Service end-to-end — hosted agents, runtime, enterprise deployment, monitoring, evaluations, and publishing agents to M365/Teams
  • Scope: The Agent Service product line, including its enterprise differentiation and roadmap. He personally demos agent deployment, tracing, and the full local-dev → hosted-agent → production flow.
  • Key doc: "Microsoft Foundry Agents – FY26-Q3" strategy doc lists Jeff as Product owner
  • Why he matters: He defines what "deploy to Foundry" means. If .NET agents need to land on Foundry cleanly, Jeff's team is where that happens.

Shawn Henry — Principal Group PM, Azure AI Foundry

  • Reports to: Jeff Hollan
  • Owns: Agent frameworks and SDK-layer agent architecture — specifically Semantic Kernel and AutoGen (which are converging into Agent Framework)
  • Scope: Multi-agent abstractions, orchestration patterns, and the framework-level building blocks that sit underneath Agent Service
  • Key artifact: Build session deck "Building the digital workforce: Multi-agent apps with Azure AI Foundry" where he's listed as Principal GPM for SK and AutoGen
  • Why he matters: He owns the framework layer that our MEAI and Agent Framework investments need to align with. He's the architectural peer for what we're building in .NET.

Maria Naggaga Nakanwagi — PM Lead, Foundry Toolbox

  • Reports to: Vinod Valloppillil (AI Foundry Knowledge & Tools)
  • Owns: Foundry Toolbox — the unified tool management layer for agents (MCP, OpenAPI, A2A, skills). Her explicit first priority in her new role.
  • Background: Former .NET platform PM leadership, former MCP company PM DRI. She knows our world.
  • Why she matters: Foundry Toolbox is the integration surface where .NET SDKs, MCP servers, and agent tools meet Foundry's governance and discovery layer. Maria is the single best entry point for .NET platform PMs into Foundry tooling. She speaks both languages.
  • Engagement: Schedule a 1:1 immediately. She is likely the most natural ally on the Foundry side.

Tina Schuchman — Foundry Agents / Toolbox

  • Scope: Developer friction, tool unification, MCP/A2A integration, governance under the Foundry Toolbox workstream
  • Role in meetings: Presents Foundry Toolbox architecture and motivation in AI Accelerator sessions
  • Why she matters: She's defining what "unified MCP endpoint" and "single tool catalog" look like. If .NET MCP servers need to show up in that catalog, Tina's design decisions matter.

Vinod Valloppillil — AI Foundry Knowledge & Tools (Leader)

  • Scope: Organizational leader over the Knowledge & Tools pod that includes Foundry Toolbox
  • Why he matters: If you need executive-level alignment on Foundry Toolbox direction, Vinod is the leader above Maria.

Yina Arenas — Foundry "Agent Factory" Narrative

  • Scope: Public-facing Foundry positioning. Drives "Azure AI Foundry: The Agent Factory" messaging and sessions.
  • Why she matters: She shapes how developers understand where agents live (PaaS, services, apps). That directly impacts ASP.NET Core, Aspire, and hosting stories. If .NET isn't in her narrative, it's invisible.
  • Engagement: Scenario reviews, Build/Ignite planning, GTM alignment

Marco Casalaina — TGIFoundry Demo Day Organizer

  • Scope: Runs the monthly TGIFoundry Demo Day — the most visible recurring cross-org Foundry forum
  • Why he matters: He's the gatekeeper for the best window into what Foundry is shipping and demoing month to month.

Glenn Condron — Principal PM IC (recently moved from .NET to Foundry)

  • Reports to: Jeff Hollan
  • Current scope (evolving): Glenn moved from .NET PM management to an IC PM role focused on Foundry-aligned platform and tools work. His stated areas:
    • Agent framework semantics on Foundry (agent vs. agents vs. agent host, deployment models)
    • Foundry templates and developer success (which templates live in Foundry, which graduate)
    • Foundry usability and "papercuts" (he's been building agents in the portal and feeding back friction)
    • Co-authored the ".NET Platform – FY26 Framing Update" positioning Foundry-first deployment
  • Why he matters: Glenn is the most natural bridge between our team and Foundry — he literally just walked across. His scope isn't well understood yet, even internally, but he's actively working the template and DX seam. He's someone to stay close to as his role crystallizes.

Meetings to Request Invitations To

1. TGIFoundry Demo Day

  • Cadence: Monthly
  • Organizer: Marco Casalaina
  • Audience: "Foundry Product Team and Product Friends" — intentionally cross-org
  • What happens: Demos of Foundry capabilities, agent builder updates, tools/skills/MCP developments, end-to-end developer workflows
  • Why join: Best recurring window into what Foundry is actually shipping. Low commitment, high signal. Ask Marco for an invite.

2. Foundry Agents / Toolbox Working Sessions

  • Cadence: Recurring (not clearly branded or open-invite)
  • Organizers: Tina Schuchman, Jeff Hollan
  • What happens: Roadmap, design tradeoffs, shipping milestones for Agent Service and Toolbox. Covers MCP, OpenAPI, A2A integration points.
  • Why join: This is where SDK shape and tool integration decisions get made. .NET platform should be a stakeholder here, not a downstream consumer.
  • How to join: Ask Tina or Jeff directly for inclusion as a platform stakeholder. There is no public alias — these are working sessions, not broadcast meetings.

3. AI Accelerator Series

  • Cadence: Recurring deep-dives
  • Organizers: Foundry Agent Service leadership (Jeff Hollan, Tina Schuchman present regularly)
  • What happens: End-to-end agent builds, new Agent Service capabilities, gap analysis
  • Why join: You see real apps hitting Foundry and where developers struggle — before it becomes a GitHub issue. The Jeff H. demo that prompted this whole sprint came from this series.

4. Thrive University Foundry Sessions

  • Cadence: Recurring (Jeff Hollan often speaks)
  • What happens: Foundry enablement and education
  • Why join: Lower priority but useful for understanding how Foundry is positioning itself internally to other teams.

Meetings NOT worth pursuing for this purpose

  • CoreAI Monthly Managers Workshop — Tim and David are already in this; it doesn't serve the .NET ↔ Foundry connection goal
  • Our own .NET AI meetings (.NET AI: Platform & DevEx, AI and Agents .NET Review) — Nobody from Foundry attends these. They're valuable but they're our side of the conversation, not theirs.

Foundry-Side Projects to Be Aware Of

Foundry Toolbox

  • What: Unified tool management layer abstracting MCP, REST, A2A, and skills behind a single interface. Adds tool catalog, dynamic discovery, governance, and observability.
  • Owner: Maria Naggaga (PM), Vinod Valloppillil (org leader)
  • Status: Active buildout. Maria's explicit first priority.
  • Why it matters for .NET: If .NET MCP servers and tools need to be discoverable and governable inside Foundry, Toolbox is the integration point. This is the most direct overlap with our MCP SDK work.

Foundry Agent Service

  • What: The hosted agent runtime on Foundry — deployment, monitoring, evaluation, publishing to M365/Teams
  • Owner: Jeff Hollan (product), Shawn Henry (framework layer)
  • Status: GA. Active iteration on enterprise features.
  • Why it matters for .NET: This is the deployment target for .NET agents. The path from "dotnet run" to "running on Foundry Agent Service" needs to be seamless. It currently isn't.

Foundry Templates & Developer Success

  • What: Which project templates live inside the Foundry portal, which graduate to the .NET CLI, which get retired
  • Owner: Glenn Condron (actively working this seam)
  • Status: In flight. Glenn is soliciting input from our team.
  • Why it matters for .NET: The "dotnet new" → Foundry story depends on templates that actually work end-to-end. Glenn is the person making that happen.

Agent Framework Convergence (SK + AutoGen → Agent Framework)

  • What: Semantic Kernel and AutoGen are converging into Microsoft Agent Framework, built on MEAI
  • Owners: Shawn Henry (Foundry side), Jeremy Likness (our side)
  • Status: Active. Migration path and messaging still being refined.
  • Why it matters for .NET: The upgrade friction from SK to Agent Framework is real and will confuse customers. Our PMs need to understand both the Foundry framing and the .NET framing.

Recommended Immediate Actions

  1. Schedule 1:1 with Maria Naggaga — She's the Foundry Toolbox PM with deep .NET background. Highest-signal new contact.
  2. Get on TGIFoundry Demo Day — Ask Marco Casalaina. Low friction, high visibility.
  3. Ask Tina Schuchman for access to Toolbox working sessions — Frame it as .NET platform stakeholder representation.
  4. Sync with Glenn Condron on his evolving scope — He's the bridge. Understand what he's learning about Foundry from the inside.
  5. Brief Shawn Henry on our MEAI/MCP investments — He owns the framework layer on their side. Make sure he knows what .NET is shipping and where we need alignment.
Raw
interview-guide.md

Interview & Survey Guide: .NET × Foundry Customer Research

Purpose: Structured guide for MVP Summit conversations, 1P team interviews, and 3P developer calls.
Tone: Conversational, not interrogative. These are developer-to-developer conversations. Listen more than you talk.
Time: Aim for 20–30 minutes per conversation.

Before You Start

  • Don't lead with Foundry. Start with their work and let them tell you where AI fits.
  • Take notes on exact quotes — these become your customer stories.
  • If someone gives you gold, ask: "Can I use your name and team internally when I share this?" (Internal only, but good practice to confirm.)

Part 1: What Are You Building? (5–10 min)

These questions establish context. You want to understand their project before you probe on tooling.

  1. What are you working on right now that involves AI?

    • Follow-up: Is this in production, prototyping, or still exploring?

  2. Walk me through the architecture briefly — what does the AI part look like?

    • Listen for: What models/services they call, how they orchestrate, where .NET fits in the stack.

  3. What's the user-facing experience? (Chat? Copilot? Automation? Summarization? Agents?)

  4. How did you choose your AI service provider? (Foundry/Azure OpenAI, direct OpenAI, local models, AWS Bedrock, etc.)

    • If NOT Foundry: What would it take for you to use Foundry instead? What's the pull/barrier?
    • If Foundry: What made you choose it? Was .NET a factor in that decision?

Part 2: The .NET Experience (10 min)

Now probe on the developer experience. This is where the stories live.

  1. What .NET libraries or frameworks are you using for the AI parts?

    • Prompt if needed: Microsoft.Extensions.AI? Semantic Kernel? Agent Framework? MCP SDK? Azure SDK directly? Something else?

  2. How did you get started? (Docs, samples, templates, a blog post, a colleague, trial and error?)

    • Follow-up: How was that getting-started experience? What was the first thing that tripped you up?

  3. What's the hardest thing about building this with .NET today?

    • Let them vent. This is the money question. Stay quiet and let them talk.

  4. Is there anything you had to build yourself that you expected to exist?

    • Listen for: Missing abstractions, glue code, things they pulled from other ecosystems.

  5. Have you tried migrating from Semantic Kernel to Agent Framework?

    • If yes: How'd it go? What was confusing? What broke?
    • If no: Are you aware of Agent Framework? What would motivate you to switch?

  6. What's your tooling setup? (VS, VS Code, Rider, CLI?)

    • Follow-up: Is there anything your IDE could do to make the AI development workflow better?

Part 3: Foundry Connection (5 min)

Only go here if the conversation hasn't already covered it. Don't force it.

  1. When you connect to Azure AI / Foundry, how does that work in your code?

    • Listen for: Configuration pain, auth friction, model discovery, deployment confusion.

  2. Have you used the Foundry portal (ai.foundry.com)?

    • If yes: What do you use it for? Does it connect well to your .NET development workflow?
    • If no: Why not? What do you use instead to manage models/deployments?

  3. If you could wave a magic wand and change one thing about the .NET → Foundry experience, what would it be?

Part 4: Quick Reactions (2–3 min)

Use these as lightweight probes — not every conversation needs all of them.

  1. "I can go from dotnet new to a working AI agent connected to Foundry in under 10 minutes."

    • True or false for you? What's missing to make that real?

  2. "The .NET ecosystem for AI feels like it's keeping up with Python."

    • Agree, disagree? Where does it fall short?

  3. What's one thing another ecosystem (Python, TypeScript, etc.) does for AI developers that you wish .NET had?

Wrap-Up

  1. Is there anyone else on your team or in your network I should talk to about this?

  2. Anything I didn't ask that I should have?

After Each Conversation

Capture these immediately (even bullet points are fine):

Field Notes
Name / Team / Org
What they're building
AI service provider (Foundry / OpenAI direct / other)
Key .NET libraries used
Biggest friction point
Unmet need / wish
Foundry-specific feedback
Quotable moment (exact words if possible)
Follow-up needed?

For Survey Distribution (Async)

If you need a shorter async version (e.g., email to a broader set of 1P contacts), use these 5 questions:

  1. Are you building AI-powered features or services with .NET today? (Yes — in production / Yes — prototyping / No — planning to / No)
  2. What AI service do you connect to? (Azure Foundry / Azure OpenAI / OpenAI direct / Local models / Other: ___)
  3. What .NET libraries do you use for AI? (M.E.AI / Semantic Kernel / Agent Framework / MCP SDK / Azure SDK / Other: ___)
  4. What is the biggest friction point in your .NET + AI development workflow? (open text)
  5. What's one thing that would make you more likely to use Azure Foundry with .NET? (open text)
Raw
mission-brief-short.md

Mission Brief: .NET × Foundry — Customer Clarity Sprint

From: David Ortinau | To: [PM 1], [PM 2]
Sprint: March 19 – April 1 | Review: April 2 with Tim, Cathy, David

The Problem

Driving Foundry adoption is a top business goal. We own the .NET developer experience connecting to Foundry — M.E.AI, MCP SDK, Agent Framework, Aspire, tooling, templates, docs — but we don't have clear, grounded answers to:

  1. What are .NET developers actually doing when building agentic apps today, with and without Foundry?
  2. Where do they hit friction, fall off, or work around us?
  3. What should we invest in to pull more .NET developers toward Foundry?

What We Need Back

By March 31 (draft) → April 2 (review):

Customer Stories (5–8): Real, named scenarios — not composites. Each one paragraph: who they are, what they're building, how they connect to AI, where they struggle, what they need.

Your Own Hands-On Experience: Both of you should build something real — take the .NET → Foundry path end-to-end as a developer would. Start from dotnet new or the public docs. Deliver a candid, one-page first-person narrative of the journey: what was smooth, what was confusing, where you got stuck, where you almost gave up, what was surprisingly good. Your frustrations and delights are signal too — distinct from what customers report.

Foundry Team Alignment: Establish working relationships with Foundry PMs (Shawn Henry, Jeff Hollan). Schedule 1:1s, identify working groups and decision forums we should have a seat at, and map where our roadmaps align. Deliver a half-page summary: who you met, what forums exist, where the alignment is, and recommended next steps. The goal is a durable connection, not a one-time conversation.

Opportunity Map: Prioritized list of investments across libs, tools, templates, docs, and samples. For each: what it is, who it unblocks (tie to a story or your own experience), and whether it's validated or hypothesis. Think in three buckets: quick wins, force multipliers, and missing pieces.

How to Get There

  • Start with what exists: Read Cathy's doc — it's fresh; validate, challenge, extend. Watch Jeff H.'s AI Accelerator demo. Jeff's demo is the Foundry team's own story — pressure-test it: when we tell it with C# and .NET, what holds up and what doesn't?
  • Talk to people: MVP Summit (next week) — you're hosting sessions with the target audience. Also: 1P teams via Foundry Kusto dashboard, 3P interviews, GitHub/social signal. Foundry-side contacts: Jeff Hollan, Shawn Henry.
  • Note on Semantic Kernel: SK is replaced by Agent Framework. Only relevant for upgrade friction and confusion — not a standalone investment area.
  • Async check-in end of week 1 (March 27).

The Lens

We're not just cataloging .NET + AI pain. We're asking: what .NET investments drive developers to Foundry? Every opportunity should connect back to that.

Questions → grab David. Move fast, stay grounded.

Raw
mission-brief.md

Mission Brief: .NET × Foundry — Customer Clarity Sprint

Issued by: David Ortinau, .NET Platform and Tooling
Assigned to: [PM 1], [PM 2] — fully collaborative
Sprint: March 19 – April 1, 2026
Review: April 2, 2026
Stakeholders: Tim Heuer, Cathy Sullivan, David Ortinau

Why This Matters

Driving adoption of Azure Foundry is a top-line business goal. As the .NET platform and tooling team, we own the developer experience for the largest enterprise language ecosystem connecting to Foundry — but we lack a clear picture of what's working, what's broken, and where the biggest opportunities are. We're investing in Microsoft.Extensions.AI, MCP SDK, Microsoft Agent Framework, .NET Aspire, templates, docs, and samples — but we can't say with confidence whether these investments are pulling developers toward Foundry, or whether they hit a wall trying.

This sprint closes that gap.

Mission

In two weeks, deliver customer-grounded clarity on two questions:

Question 1 — What's the current state?

What are .NET developers actually doing today when building agentic apps, services, and experiences — with and without Foundry?

Question 2 — Where should we invest?

What friction, gaps, and opportunities exist across our full stack (libraries, tooling, templates, docs, samples) that, if addressed, would drive .NET developers to choose and succeed with Foundry?

Deliverables

Deliver one artifact with two parts, in whatever format best serves portability and engagement (deck, written brief, or hybrid). It must be concise enough to present in 30 minutes and compelling enough to forward to skip-levels.

Part 1: Customer Stories (The State)

5–8 concrete customer stories that answer:

  • Who are the .NET developers building with AI today? (1P and 3P, segments)
  • What are they building? (agentic apps, copilots, service integrations, etc.)
  • How are they connecting to AI services? (Foundry, direct OpenAI, local models, other)
  • Where do they fall off? (specific friction points, abandonment moments, workarounds)
  • What did they wish existed? (unmet needs, expressed or inferred)

Each story should be a named, real scenario — not a composite. Format: "[Customer/segment] is building [thing] using [stack]. They hit [friction]. They need [gap]." One paragraph each, max.

Part 2: Your Own Hands-On Experience (The Lived Reality)

Before you can credibly assess customer friction, you need to feel it yourself. During this sprint, both of you should build something — take the .NET → Foundry path end-to-end as a developer would.

The activity:

  • Pick a realistic scenario (e.g., build an agentic app with Agent Framework connected to Foundry, stand up an MCP server, use M.E.AI to call a Foundry-hosted model from an Aspire app).
  • Start from dotnet new or the docs getting-started page. Use the public docs, samples, and templates — not insider knowledge.
  • Take notes as you go: what's smooth, what's confusing, where you get stuck, where you have to leave the .NET ecosystem to make progress.

The deliverable: A candid, first-person account of your experience. Not a bug list — a narrative. "Here's what I tried to build, here's what the journey felt like, here's where I almost gave up, here's what was surprisingly good." One page max. Include screenshots of friction points if useful.

This is distinct from the customer stories — it's your professional judgment as PMs who live in this space. Your frustrations and delights are signal too.

Part 3: Foundry Team Alignment (The Relationships)

We can't drive Foundry adoption in isolation. As part of this sprint, establish working relationships with the Foundry PM team — starting with Shawn Henry and Jeff Hollan.

The activity:

  • Schedule introductory 1:1s with Shawn and Jeff. Come prepared with early findings from customer research and your own hands-on experience — don't show up empty-handed.
  • Identify the working groups, planning cadences, and decision forums where Foundry product direction gets shaped. Which ones should .NET platform and tooling have a seat at?
  • Understand their roadmap priorities and where they see .NET fitting (or not fitting) into their story.

The deliverable: A brief summary (half page) covering:

  • Who you met with, their roles, and what they own
  • What forums/working groups exist that we should participate in (name, cadence, who runs them, how to join)
  • Where the alignment opportunities are — places where our investments and their roadmap reinforce each other
  • Recommended next steps — specific meetings to set up, groups to join, or recurring touchpoints to establish

The goal is not just information — it's a durable connection. We want to leave this sprint with an ongoing channel to the Foundry team, not a one-time data dump.

Part 4: Opportunity Map (The Investment)

A prioritized view of opportunities across the full .NET-to-Foundry stack:

Category Description
Quick wins DevEx improvements on existing libs, rough edges in tooling, low-effort / high-signal fixes
Force multipliers Investments that make the .NET → Foundry path dramatically better (the "holy crap" ideas)
Missing pieces Things that don't exist yet but should — gaps in the end-to-end story

For each opportunity, state:

  • What it is (one sentence)
  • Who it unblocks (tie back to a customer story)
  • Confidence (validated by research vs. hypothesis)

Methodology & Key Inputs

Customer Research Channels (prioritized)

  1. MVP Summit (week of March 23) — You're there and hosting sessions with the target audience. This is the highest-signal opportunity. Use the attached interview guide to structure conversations. Every hallway chat is data.
  2. 1P contacts via Kusto — Foundry usage dashboard is available (ask David for access if needed). Use this to identify internal teams using .NET + Foundry. Name people and teams freely — this is internal only, no permissions needed.
  3. Foundry team contacts — Jeff Hollan and Shawn Henry are your starting points on the Foundry side. Ask them what they see in their telemetry about .NET usage and where they see gaps.
  4. 3P customer interviews — Schedule 3–5 external developer interviews through existing PM relationships. No incentive budget — rely on goodwill and the value of being heard.
  5. GitHub issues & social — Scan for signal in existing issues (M.E.AI, MCP SDK, Agent Framework repos) and social channels (Twitter/X, Reddit, Discord).

Key Reference Materials

  • Existing research: Cathy's prior analysis — this is fresh work. Start here. Your job is to validate, challenge, and extend it — not redo it.
  • North star demo: Jeff H.'s AI Accelerator recording (March 5) — Watch this before anything else. This is the Foundry team's own telling of the story. Your job is to pressure-test: When we tell that same story with C# and .NET, what holds up? What's missing? What rings hollow?

Scope

In scope: Everything a .NET developer touches on the path from "I want to build an AI-powered app" to "I'm running it in production connected to Foundry."

  • Libraries: Microsoft.Extensions.AI, MCP SDK, Microsoft Agent Framework
  • Platforms: .NET Aspire, ASP.NET Core, .NET MAUI, Blazor
  • Tooling: VS, VS Code, CLI (dotnet new, etc.)
  • Content: Templates, samples, docs, getting-started experience
  • Migration: Semantic Kernel → Agent Framework transition (SK is replaced by Agent Framework; matters in terms of upgrade friction and confusion)

Out of scope:

  • Foundry platform/service issues that aren't .NET-specific
  • Pricing, licensing, or commercial terms
  • Competitive analysis (unless a customer explicitly cites an alternative)
  • Semantic Kernel as a standalone investment (it's being replaced by Agent Framework)

Operating Principles

  1. Stories over statistics. One named customer scenario is worth more than an aggregate number right now. We need to feel the developer journey, not just measure it.
  2. Grounded, not aspirational. Every opportunity you flag should tie back to a real customer pain or behavior you observed. Label anything that's a hypothesis.
  3. Bias toward Foundry pull. We're not just cataloging .NET + AI problems — we're specifically looking for where .NET investments can drive developers to Foundry. Keep that lens.
  4. Start from what exists. Read Cathy's doc. Watch Jeff's demo. Build on prior work, don't restart.

Success Criteria

On April 2, the review audience should walk away able to answer:

  • "I can name 5+ real .NET developer scenarios building with AI today and what they need."
  • "I know where developers fall off the .NET → Foundry path and why."
  • "I've heard firsthand from the PMs what the experience feels like — not just what customers say."
  • "I know who to call on the Foundry team and what working groups we need to be in."
  • "I can see 3–5 prioritized investments we should make and who they unblock."
  • "I can articulate why these investments drive Foundry adoption, not just .NET satisfaction."

Logistics

  • Check-in: Brief async update at end of week 1 (March 27) — what you've learned, any pivots needed.
  • Draft review: Share draft with David by March 31 for feedback before the April 2 review.
  • Final review: April 2 with Tim, Cathy, and David. 30 minutes. Come ready to discuss, not just present.

Questions? Grab David. This is a sprint — move fast, stay grounded, and bring us back stories that make the path forward obvious.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment