Inside Microsoft Foundry Toolkit for VS Code: Architecture, Agent Inspector, and the Debug-to-Deploy Pipeline

Meta Description: Microsoft Foundry Toolkit for VS Code merges AI Toolkit and the Foundry extension into one tool. This deep dive covers its architecture, local agent debugging with Agent Inspector, the Responses/Invocations protocol, and the code-to-cloud deployment path for Microsoft Foundry hosted agents.

Day 37 of 100 — Microsoft Foundry 100 Days / 100 Blogs

You've built a hosted agent for Microsoft Foundry. It runs beautifully — in your head. The first time you actually see what the model is thinking, which tool call fired, and why the response came back malformed, is in a cloud trace, three deploys later, after the pipeline finished and the bill already posted.

That workflow is backwards, and until recently there wasn't a good local alternative for Foundry's code-first hosted agents. You could test prompt agents in the Foundry portal playground, but as soon as your "agent" became an actual Python or C# process implementing the Responses protocol with Microsoft Agent Framework, your debugging options shrank to print() statements and hope.

Microsoft Foundry Toolkit for Visual Studio Code closes that loop. It is not a new idea — it's the unification of two tools developers were already juggling (AI Toolkit and the standalone Microsoft Foundry extension) into a single surface that spans local models, local agent debugging, and cloud deployment, all without leaving the editor. This article is a systems-level walkthrough of how it actually works: what's local, what's remote, what protocol glues the two together, and where the architecture has sharp edges you need to know about before you build on top of it.

Why This Matters

Foundry's hosted agent model (which we covered in Day 21 — Agent Endpoints and Day 31 — azd ai CLI) deliberately separates your code from Foundry's hosting infrastructure. That separation is good for production — Foundry manages scaling, identity, and networking — but it creates a classic inner-loop problem: how do you iterate quickly on agent code that's ultimately going to run inside someone else's container runtime?

Three options existed before Foundry Toolkit matured into its current form:

1. Deploy and pray — push every change to Foundry Agent Service and debug via cloud traces. Slow, expensive, and terrible for exploratory debugging.
2. Local HTTP server + manual curl/Postman — functional, but you lose streaming inspection, tool-call visibility, and breakpoint correlation.
3. Full local emulation — doesn't really exist, because hosted agents call real cloud models and real tools; there's no meaningful way to fully air-gap the loop.

Foundry Toolkit formalizes option 2 and makes it dramatically better by giving you a purpose-built inspector that understands the agent protocol, correlates it with your debugger, and then hands off directly to deployment. Understanding this tool's architecture matters because it reveals how Microsoft expects the entire Foundry developer lifecycle to work: local-first iteration, cloud-only inference, and a deployment boundary that's explicit rather than implied.

Table of Contents

1. What Foundry Toolkit Actually Is
2. Architecture: Three Panels, Two Resource Planes
3. The Local Model Story: ONNX, Ollama, and Foundry Local
4. Agent Builder vs. Hosted Agent Code Projects
5. Agent Inspector: The Core Engineering Piece
6. Protocol Detection: Responses vs. Invocations
7. The Debug-to-Deploy Pipeline
8. Implementation Walkthrough
9. Real-World Developer Scenario
10. Production Considerations
11. Security Considerations
12. Performance and Cost Considerations
13. Common Mistakes and Pitfalls
14. Alternatives and Trade-offs
15. Practical Recommendations
16. Conclusion
17. References

What Foundry Toolkit Actually Is

Foundry Toolkit for VS Code is the rebrand and merger of two previously separate extensions:

• AI Toolkit — the local-first extension for model catalog browsing, prompt experimentation, local fine-tuning, and ONNX/Ollama model management.
• Microsoft Foundry extension — the cloud-resource-centric extension for browsing Foundry projects, deploying agents, and running evaluations.

Rather than maintaining two extensions with overlapping agent and model concepts, Microsoft consolidated them. The result is one Activity Bar icon with three top-level sections: My Resources, Developer Tools, and Help and Feedback. This matters architecturally because it means the extension now has to reconcile two different resource models in a single UI: local filesystem/process-based resources (a model running via Ollama on your GPU) and cloud ARM-based resources (a Foundry project's deployed model endpoint). The extension's job is to present both through a consistent resource tree without pretending they're the same thing.

If you've used the Foundry MCP Server we covered in Day 26, you might wonder how it relates to the Toolkit. They solve different problems: the MCP Server exposes Foundry's control plane as MCP tools so any MCP-aware coding agent (including GitHub Copilot in agent mode) can query and mutate Foundry resources conversationally. Foundry Toolkit, in contrast, is a traditional GUI extension with dedicated panels, webviews, and debug integrations — it's the IDE surface, not a tool-calling interface. In practice, teams use both: the MCP Server for "ask Copilot to check my project's quota," and the Toolkit for "open Agent Inspector and step through this tool call."

Architecture: Three Panels, Two Resource Planes

The extension's three sections map cleanly onto a mental model worth internalizing:

Section	Resource Plane	What Lives Here
My Resources	Both	Models (local + cloud), agents (prompt + hosted), tools, knowledge sources, evaluations — scoped to whatever Foundry project is currently selected as default, plus anything local (ONNX models, local prompt files)
Developer Tools	Mostly local, triggers remote actions	Model Catalog, Model Playground, Agent Builder, Tool Catalog, Agent Inspector, deployment commands
Help and Feedback	N/A	Docs, release notes, Copilot-assisted onboarding

The critical design decision is that project selection is global state for the session. You sign in to Azure through the Azure Resources extension (Foundry Toolkit doesn't reimplement Azure auth — it depends on the shared Azure Account provider that most Azure extensions in VS Code use), then pick one Foundry project as your default. Every cloud-scoped action in "My Resources" — browsing models, deploying agents, viewing evaluations — operates against that single default project until you explicitly switch it.

This single-default-project model is a deliberate simplification. It avoids the complexity of multi-project context switching inside every single panel, at the cost of requiring an explicit "Switch project" action when you're working across multiple Foundry projects (for example, a dev project and a staging project) in the same session. If you're scripting a multi-project workflow, you're better off using the Foundry SDK or azd ai directly rather than fighting the extension's single-context model.

The Local Model Story: ONNX, Ollama, and Foundry Local

One of the more interesting architectural decisions is that Foundry Toolkit treats Foundry Local (the on-device inference runtime we covered in Day 4), ONNX Runtime models, and Ollama-hosted models as first-class citizens in the same Model Catalog as cloud-hosted Foundry Models. From a developer's perspective this is just "more models to pick from" in the playground, but architecturally it means the extension's model abstraction layer has to normalize at least three different runtime contracts:

• Foundry Models (cloud): OpenAI-compatible or Azure AI Inference API over HTTPS, authenticated via Entra ID or API key, billed per token.
• Foundry Local: a local inference server (built on ONNX Runtime / foundry-local-cli) exposing an OpenAI-compatible endpoint on localhost, with hardware-aware model variant selection (CPU/GPU/NPU).
• Ollama: a separate local daemon with its own API surface, which the extension has to speak natively or proxy.

The Toolkit also supports converting, quantizing, and evaluating models for local Windows deployment, plus profiling CPU/GPU/NPU usage for supported ML workloads — capabilities inherited directly from AI Toolkit's machine-learning engineering roots, not something a typical "cloud resource browser" extension would normally own. If you're doing on-device model work (quantizing a small model to run efficiently on a Copilot+ PC's NPU, for instance), this is genuinely one of the few IDE-integrated workflows for that today, and it's worth exploring even if you never touch Foundry's cloud side.

For hosted agent development specifically, the local-model story is less relevant — hosted agents calling Foundry Models still make real network calls to Azure during local debugging. There is no "offline hosted agent" mode. Keep this distinction clear: the model catalog has local options, but hosted agent execution does not become local just because the editor is.

Agent Builder vs. Hosted Agent Code Projects

Foundry Toolkit draws a hard architectural line between two agent creation paths, and conflating them is the single most common source of confusion for new users:

Agent Builder (declarative, no-code path): You configure a model, instructions, and tools through a form-based UI. This produces a prompt agent — the same resource type you'd create in the Foundry portal's Agent Playground. Prompt agents can optionally be stored locally as files during development, but "local storage" here means the configuration lives on disk — inference still happens against a cloud model. Prompt agents created this way support a narrower surface of structured-output and dataset-evaluation options compared to full hosted agents.

Hosted agent code projects (pro-code path): You scaffold from a Microsoft Agent Framework sample (Python or C#), which generates a real source tree: agent orchestration code, a requirements.txt/.csproj, a launch.json debug configuration, Dockerfile (for container deployment mode), and critically, an azure.yaml manifest compatible with azd ai (see Day 31). This is the same hosted-agent object model underpinning declarative workflow retirement — Microsoft is explicitly steering developers away from the visual Workflow Designer (deprecated per Day 7) and toward exactly this kind of code-first scaffold.

The practical implication: if you want debuggable, version-controlled, CI/CD-friendly agents, you want the hosted agent code project path, not Agent Builder. Agent Builder is for rapid configuration exploration — "does GPT-5 with these three tools answer this class of questions well" — not for building production orchestration logic.

Agent Inspector: The Core Engineering Piece

This is the part of the Toolkit that actually solves the inner-loop problem described earlier, and it's worth understanding in detail because it's the most technically interesting component.

Agent Inspector is not a replacement for cloud tracing (which we covered in Day 10 — Observability). It's explicitly described as operating on a different data source: "Live Inspector events and stored traces are separate data sources. Use Inspector for interactive local debugging and tracing for recorded telemetry." That's an important architectural distinction — Inspector is ephemeral, in-memory, and tied to your current debug session; OpenTelemetry traces shipped to Application Insights are durable, queryable, and tied to deployed runtime identity.

How it connects

1. You start your agent's HTTP server locally using the project's generated debug configuration (for Python samples, this is typically a debugpy-attached launch config hitting http://localhost:8088).
2. You open the Agent Inspector panel from Developer Tools > Build > Agent Inspector.
3. Inspector connects to the configured endpoint (editable via a pencil icon if your server runs on a different port) and auto-detects the protocol — Responses or Invocations — by probing the endpoint's behavior.
4. You send a message through Inspector's playground UI. This becomes a real HTTP request to your local process.
5. If you've set breakpoints in your agent code, execution pauses exactly as it would for any other VS Code debug session — you can inspect local variables, call stacks, and step through orchestration logic.
6. Inspector renders the response stream, including intermediate tool calls, as they arrive — not just the final text.

The critical caveat documented directly in Microsoft's own guidance deserves emphasis because it's easy to miss: a local agent can call cloud models and live tools. Inspector does not mock anything. If your agent code calls a Bing grounding tool, a real OpenAPI-backed tool (see Day 36), or a file search index, those calls go out for real and can incur real charges or side effects. Treat local debugging sessions with Inspector the same way you'd treat a staging environment, not a sandbox.

Protocol Detection: Responses vs. Invocations

We went deep on this distinction in Day 2, but it's directly relevant to how Inspector works under the hood, so a quick recap with new context:

• Responses protocol: the OpenAI-compatible, streaming-first protocol used by most Agent Framework samples. Single-turn request/response semantics with server-sent event streaming for incremental output and tool calls.
• Invocations protocol: Foundry's own protocol designed for more complex multi-turn, potentially long-running agent interactions, including the suspend/resume semantics used for human-in-the-loop approval gates (Day 16) and steerable conversations (Day 18).

Inspector's documentation states the main supported path uses the Responses protocol, and that "available views depend on the protocol and diagnostics that your agent server provides." This tells you something architecturally important: Inspector isn't a generic HTTP client with a pretty UI — it has protocol-aware rendering logic that changes behavior based on what your server speaks. If you're building a long-running or steerable agent using the Invocations protocol, expect a less complete debugging experience in Inspector today than you'd get for a straightforward Responses-based agent. This is a reasonable trade-off given Invocations is the newer, preview-stage protocol, but it's a real gap worth planning around if your architecture leans heavily on suspend/resume patterns.

The Debug-to-Deploy Pipeline

Once your agent behaves correctly under Inspector, deployment happens from the same extension, collapsing what used to be a context switch into the editor's cloud explorer action set:

# azure.yaml — generated by the hosted-agent scaffold, consumed by both
# the Foundry Toolkit "Deploy" command and the azd ai CLI (Day 31)
name: my-hosted-agent
metadata:
  template: foundry-agent-framework-python@0.1.0
services:
  agent:
    project: ./src
    language: python
    host: ai.agent
    config:
      deploymentType: code        # or "container"
      packageMode: remote         # build happens server-side; no local Docker needed

The Toolkit's deploy command reads this same manifest. Two deployment modes matter here:

• Code deployment, remote package mode: your source is zipped and sent to Foundry, which builds and runs it. This is the default and doesn't require Docker locally — a deliberate simplification for developers who don't want to manage container builds.
• Container deployment: you supply a Dockerfile and push to Azure Container Registry (see the registry/OIDC requirements we covered in Day 13 — Skill Supply Chain Security). This gives you full control over the runtime environment at the cost of managing your own image pipeline.

After deployment, the Hosted Agent Playground inside the Toolkit lets you test the deployed version, inspect its logs and traces, and manage versions — effectively the same workflow as Inspector, but now pointed at Foundry Agent Service instead of localhost. This is the moment your agent transitions from "debuggable local process" to "versioned, RBAC-governed Foundry resource" with the identity model we described in Day 3 — Autopilots and Day 24 — Entra Agent ID.

Implementation Walkthrough

Here's a realistic end-to-end sequence for building and shipping a hosted agent entirely through Foundry Toolkit.

1. Install the DevPack, not just the Toolkit

# DevPack installs: Foundry Toolkit, azd + azd ai, Foundry Canvas,
# and the Microsoft Foundry Skill for coding-agent integration
# (VS Code command palette)
> Foundry: Install Foundry DevPack

Installing only the Toolkit extension gets you the GUI; DevPack gets you the full terminal + editor + coding-agent loop, which is what you actually want for serious hosted-agent development.

2. Sign in and set your default project

Activity Bar → Azure → Sign in to Azure
Activity Bar → Foundry Toolkit → My Resources → Set Foundry Project → Switch project

This binds the session to one Foundry account/project pair. All subsequent cloud actions (model browsing, deployment, evaluation) are scoped to it.

3. Scaffold a hosted agent from a Microsoft Agent Framework sample

Foundry Toolkit → Developer Tools → Build → Create Agent
  → "Hosted agent (code-based orchestration)"
  → Select sample: "Single-agent with function tools (Python)"
  → Target folder: ./my-hosted-agent

This generates the source tree, azure.yaml, requirements.txt, and a .vscode/launch.json with a Debug Local Agent HTTP Server configuration pre-wired to debugpy.

4. Implement and debug your agent code

# agent_server.py (simplified, generated-scaffold style)
# Demonstrates a single function-tool hosted agent using the
# Responses protocol via Microsoft Agent Framework.

from agent_framework import ResponsesAgent, tool
from agent_framework.azure import AzureAIAgentClient

@tool(description="Look up current inventory count for a SKU")
def get_inventory(sku: str) -> dict:
    # In production this calls a real inventory service.
    # Set a breakpoint on the next line to inspect `sku` in Agent Inspector.
    return {"sku": sku, "count": 42, "warehouse": "SEA-1"}

client = AzureAIAgentClient(
    # Model deployment resolved from the Foundry project bound in step 2
    model_deployment_name="gpt-5-mini",
)

agent = ResponsesAgent(
    client=client,
    instructions=(
        "You are a warehouse operations assistant. "
        "Always check inventory before promising stock to a customer."
    ),
    tools=[get_inventory],
)

# This app object is what the generated launch.json points debugpy at.
app = agent.as_asgi_app()

Press F5 on the Debug Local Agent HTTP Server configuration. In Agent Inspector, send: "Do you have SKU AB-1200 in stock?" — set a breakpoint inside get_inventory, confirm the model is actually invoking your tool (rather than hallucinating an answer), and inspect the exact arguments it passed.

5. Deploy once it behaves correctly

Foundry Toolkit → My Resources → Agents → my-hosted-agent → Deploy
  → Deployment type: Code (remote package mode)
  → Confirm region supports hosted agents

Or, equivalently, from the terminal using the same manifest:

azd ai agent deploy --project ./my-hosted-agent

6. Validate the deployed version

Foundry Toolkit → My Resources → Agents → my-hosted-agent → Open Hosted Agent Playground

Send the same test message against the deployed endpoint and compare behavior, latency, and trace output against your local Inspector session. Differences here usually point to environment variable drift, managed-identity permission gaps, or network egress policy (Day 20) blocking a call that worked locally under your own developer credentials.

Real-World Developer Scenario

Consider a fulfillment-operations team building a hosted agent that answers inventory questions and, when approved, triggers reorders through an internal procurement API. The team's actual workflow using Foundry Toolkit looks like this:

1. Prototype fast with Agent Builder to validate that a given model/tool combination can correctly reason about multi-SKU questions — no code yet, just configuration and prompt iteration in the Foundry Playground embedded in the Toolkit.
2. Graduate to a hosted agent code project once the team needs the reorder side effect gated behind a human-in-the-loop approval step (the suspend/resume pattern from Day 16), since Agent Builder's prompt agents don't support that orchestration complexity.
3. Debug tool-call correctness locally with Agent Inspector against a sandboxed procurement API environment — critically, pointing the local agent's tool configuration at a non-production procurement endpoint precisely because Inspector makes real calls.
4. Deploy to a dev-tier Foundry project first, validate against the Hosted Agent Playground, then promote the same container image to a production-tier Foundry project using the canary endpoint routing covered in Day 21.
5. Monitor post-deployment using the OpenTelemetry trace pipeline from Day 10 — Inspector is no longer in the picture once the agent is live; production debugging goes through traces, not the local debugger.

This flow illustrates the intended division of labor cleanly: Foundry Toolkit owns the "write code, verify logic, deploy" phases; Foundry's cloud observability stack owns everything after that handoff.

Production Considerations

• Don't treat Inspector sessions as your test suite. Interactive debugging is for exploration, not regression coverage. Pair it with the dataset-based evaluation workflows (cloud evaluation SDK, agentic evaluators from Day 12) for anything you want to run repeatably in CI.
• The generated launch.json is opinionated. Microsoft's own guidance explicitly warns: "Don't replace its launch files with a generic configuration." The scaffold wires working directory, interpreter, and debugger flags together in ways that are easy to break with a well-intentioned "cleanup."
• Local-to-cloud parity isn't automatic. A local debug session runs under your Azure identity and your local environment variables. The deployed hosted agent runs under its own managed identity / Entra Agent ID with its own RBAC grants and network policy. Passing locally is necessary but not sufficient evidence the deployed version will work.
• Container vs. code deployment changes your debugging story going forward. If you pick container deployment mode, make sure your Dockerfile mirrors the same entrypoint and environment setup your local launch.json uses, or you'll end up debugging two divergent runtime configurations.

Security Considerations

• Role rename awareness: Foundry RBAC roles were recently renamed (Azure AI User → Foundry User, Azure AI Owner → Foundry Owner, Azure AI Account Owner → Foundry Account Owner, Azure AI Project Manager → Foundry Project Manager). Source-code deployment specifically requires Foundry Project Manager at project scope, which bundles agent operations with role-assignment permissions — a meaningfully broad grant. Audit who has this role; it's more powerful than it sounds.
• Local credentials in play during debugging: Because Inspector routes through your local agent process, any cloud calls it makes during a debug session use whatever credential chain your local environment resolves (typically your signed-in Azure CLI/VS Code identity via DefaultAzureCredential). This means your personal identity's permissions — not the deployed agent's managed identity — gate what tools and models you can exercise locally. Don't assume parity between "what I could do while debugging" and "what the deployed agent can do."
• Container deployment requires registry access controls: if you use container deployment mode, apply the same BYO-registry OIDC trust boundary discipline covered in Day 13 — the Toolkit doesn't change that supply-chain security model, it just gives you a GUI button that triggers it.
• Inspector makes real tool calls, including to internal systems. Treat any tool endpoint reachable from a local debug session as something that needs the same access scoping you'd apply in staging — not an afterthought "it's just local."

Performance and Cost Considerations

• Local debugging still bills cloud inference. Every message you send through Agent Inspector that reaches a Foundry Model deployment consumes tokens against your quota exactly like production traffic. Teams doing heavy interactive debugging against expensive reasoning models should budget for this — it's easy to underestimate how much a day of breakpoint-driven iteration costs against a premium model tier.
• Remote package mode deployment avoids local build overhead but means your build logs and failure modes surface server-side; factor in slightly longer deploy iteration cycles than a local Docker build-and-run loop, especially for larger dependency trees.
• Local model work (ONNX/Ollama/Foundry Local) is comparatively free to iterate on since it runs on your own hardware — if you're in the experimentation phase and don't yet need cloud-grade reasoning, prefer local models in the playground before switching your Agent Builder config over to a billed Foundry Models deployment.
• NPU/GPU profiling tools only apply to supported Windows ML workloads for local model optimization — they don't give you cost/performance visibility into hosted agent cloud execution; for that, you're back to Application Insights-based tracing.

Common Mistakes and Pitfalls

1. Confusing Agent Builder prompt agents with hosted agent code projects, then being surprised that structured output and dataset evaluation options differ between the two. They are architecturally distinct resource types with different capability surfaces.
2. Assuming Inspector mocks tools and models. It doesn't. Teams have accidentally triggered real procurement/ticketing side effects during "just debugging" sessions because a tool call went through for real.
3. Editing the generated launch.json into a generic configuration, breaking the alignment between debugger, interpreter, and working directory that the scaffold carefully set up.
4. Forgetting the single-default-project model and wondering why a deployment landed in the wrong Foundry project — always confirm the active project under My Resources before running a deploy command.
5. Debugging exclusively against the Responses protocol and then being caught off guard by reduced Inspector visibility when the team later adopts Invocations-protocol features like suspend/resume or steerable conversations.
6. Skipping DevPack and installing only the Toolkit extension, then manually reinstalling azd, azd ai, and Foundry Canvas separately — DevPack exists precisely to avoid this fragmented setup.

Alternatives and Trade-offs

Approach	Best for	Trade-off
Foundry Toolkit + Agent Inspector	Interactive, breakpoint-level local debugging during active development	Still makes real cloud calls; GUI-bound; less scriptable than CLI
Foundry MCP Server + Copilot agent mode	Conversational control-plane queries/mutations from any MCP-aware tool	No visual debugger, no breakpoint correlation — better for "do this" than "why did this happen"
azd ai CLI alone	Scripted, reproducible deploy pipelines, CI/CD integration	No interactive local debugging story; you still need another tool (Toolkit, pdb, logging) for the inner loop
Manual HTTP client (curl/Postman) + print-based debugging	Teams avoiding extension dependencies entirely	Loses streaming/tool-call visualization and debugger correlation; slower iteration
Cloud-only tracing (App Insights) as your debug loop	Post-deployment behavior analysis	Expensive and slow as an iteration loop; fine as a verification loop

The realistic answer for most teams is "all of the above, at different stages": Toolkit/Inspector for writing and fixing agent code, azd ai for repeatable deployment, MCP Server for ambient control-plane tasks inside Copilot, and App Insights tracing for anything post-deployment.

Practical Recommendations

• Install the Foundry DevPack, not the bare Toolkit extension, if you're doing serious hosted-agent development — it gets you the CLI, Canvas, and Skill integration in one step.
• Default to hosted agent code projects over Agent Builder prompt agents the moment your orchestration needs real control flow, human-in-the-loop gates, or multi-agent coordination.
• Point local debugging sessions at non-production tool endpoints wherever your architecture allows a dev/staging split — Inspector's "no mocking" behavior makes this a real operational requirement, not a nice-to-have.
• Treat the generated launch.json/scaffold files as generated artifacts you extend, not templates you rewrite.
• Use Inspector for correctness, cloud evaluation datasets for regression safety — they are complementary, not substitutes for each other.
• Budget model spend for local debugging sessions separately from production inference spend if you're on a shared quota, especially for provisioned throughput deployments (Day 17) where capacity contention is a real constraint.

Conclusion

Foundry Toolkit for VS Code isn't flashy, and it's easy to undersell it as "just an extension that merged two other extensions." But the architecture underneath reveals something more deliberate: Microsoft has drawn a clear boundary between local iteration (model catalog browsing, prompt experimentation, breakpoint-level agent debugging) and cloud execution (real model inference, real tool calls, real hosted infrastructure), and then built a genuinely useful bridge across that boundary in the form of Agent Inspector and the integrated deploy pipeline.

If you're building hosted agents for Microsoft Foundry and you're still debugging with print statements and cloud redeploys, this is the tool that gets you back a real inner development loop — just remember that "local" here means local process, not local inference. Every message you send is still a real request against real infrastructure, with real cost and real side effects. Install the DevPack, scaffold a sample, set a breakpoint, and see what your agent is actually doing before your next production deploy finds out for you.

References

• Microsoft Foundry Toolkit for Visual Studio Code overview — Microsoft Learn
• Install Microsoft Foundry Toolkit for Visual Studio Code — Microsoft Learn
• Set up a Microsoft Foundry project in Visual Studio Code — Microsoft Learn
• Debug agents with Agent Inspector — Microsoft Learn
• Create hosted agents with Microsoft Foundry Toolkit for Visual Studio Code — Microsoft Learn
• Microsoft Foundry docs: What's new for August 2026 — Microsoft Learn
• Foundry Toolkit release notes (WHATS_NEW.md) — GitHub
• Series cross-references: Days 2, 3, 4, 7, 10, 12, 13, 16, 17, 18, 20, 21, 24, 26, 31 of this 100-day series (linked inline above)

(verify exact RBAC role rename terminology and current Inspector protocol support against the latest Foundry Toolkit release notes before publishing to production audiences, as this is an actively evolving preview surface)

---

This is Day 37 of the **Microsoft Foundry 100 Days / 100 Blogs* series — one deep technical dive into Microsoft Foundry every day. Follow along for daily coverage of agents, models, evaluation, security, and the engineering decisions behind them.*