Monday, November 2, 2026 Daily Edition
Data Dive Daily

DISPATCHES FROM THE MICROSOFT AI ECOSYSTEM

5 min read

Building Hosted AI Agents with GitHub Copilot CLI and Microsoft Foundry

Low-code agent builders get you moving fast. Describe what you want, click through a wizard, and watch behavior show up in minutes. But notice what happens next: once an agent needs custom business logic, source control, automated setup, or integration with existing application code, that same low-code tool turns into a wall instead of a ramp.

The alternative is a coded agent, source-controlled, testable, deployable through standard infrastructure tooling. Microsoft's stack for this pairs the GitHub Copilot CLI with a Microsoft Foundry skill, and the result is agent projects that follow Foundry's conventions from the first commit rather than generic scaffolding you have to retrofit later.

Why a Skill Changes the Output

Here's what the Foundry skill actually does: it gives Copilot task-specific knowledge about how Foundry agents are structured, how to define agent configuration, connect to a Foundry project, choose a model, and align generated code with the Foundry development workflow. No separate toolkit installation required.

In other words, Copilot isn't generating boilerplate and hoping it's close enough. It's working with framework-specific context, so the resulting project matches what a working Foundry agent actually needs (a toolbox, an agent definition file, deployment infrastructure) before a developer touches a line of code.

The Toolbox Pattern

But what is a toolbox, exactly? And what does it mean for tools to be "shared" across agents? A Foundry toolbox is a reusable set of tools packaged so multiple agents can use them without duplicating work. A typical example pairs the Microsoft Learn MCP server (which retrieves official Microsoft documentation) with a web search tool for current, non-static data. Describe it in natural language, and Copilot assembles the toolbox, exposing it through an MCP endpoint you can verify on its own, separate from the agent.

Notice why this separation matters: tools get defined once and referenced by any agent that needs them, instead of copy-pasted into every project that touches them.

Project Structure

A generated Foundry agent project splits its concerns across a small set of files. Here's what that looks like:

  • main.py : the core logic. It wires a Foundry-hosted model to the toolbox, authenticates per request using bearer tokens, and serves responses over the OpenAI responses protocol.
  • agent.yaml: defines agent behavior. Type, name, description, inference protocol, hosting parameters like CPU, memory, environment variables, runtime configuration.
  • toolbox.yaml: lists the tools available to the agent.
  • azure.yaml and an infra/ folder of Bicep templates: drive deployment. Provisioning the Foundry project, model deployments, monitoring resources, container registry, hosted agent infrastructure.

Because configuration, tooling, and infrastructure each live in their own file, each one can be versioned and changed on its own. An agent's identity doesn't need to shift when its tool access changes. Neither needs to shift when the deployment target changes.

Two Ways to Test Locally

Command line. The Azure Developer CLI (azd) supports azd ai agent run to start the agent locally. It installs dependencies from requirements.txt and exposes the agent on a local port. azd ai agent invoke then submits a prompt and hands back the agent's response. This is the fast loop, useful for confirming an agent behaves reasonably before you go any further.

Agent Inspector UI. For a closer look, the Foundry toolkit's Agent Inspector shows more than output alone. It exposes the full event stream: response creation, in-progress state, reasoning tokens (relevant if you're on a reasoning model), streamed text deltas, the final response. A separate tools section shows every tool call with its inputs and outputs, and that matters the moment an agent makes several tool calls per prompt and you need to know which call produced which result.

Setting up the Inspector means running the agent as an HTTP server, plus VS Code debug configuration (task.json, launch.json). I like to hand this step to a specialized coding agent: verify the responses protocol is already in use, resolve dependency conflicts, generate the debug files. That's not a step worth doing by hand.

Tracing comes as a one-click addition through OpenTelemetry, viewable in the same Inspector UI. That's the difference between a black box and something you can actually diagnose: which tool fired, what it returned, where behavior split off from what you expected.

Deployment

Once an agent is tested, deployment stays deliberately simple. From the Inspector UI, a Deploy action packages the agent as a Docker image (typically pushed to an Azure Container Registry managed by Foundry) using an existing Dockerfile from the project. Default CPU and memory settings are usually enough for a first deployment.

Once deployed, the hosted agent shows up under the Foundry project's Hosted Agent view: status, details, traces, plus a cloud-based playground for testing the deployed version the same way you tested it locally.

What This Pattern Actually Solves

Natural language isn't replacing engineering judgment here. What's actually happening is that the tedious, error-prone parts (project scaffolding, YAML wiring, infrastructure templates, debug configuration) get generated correctly the first time, because the tooling understands the target platform's conventions. That frees up the developer's time for the parts that require judgment: what the agent should do, which tools it needs, how it should behave when context is missing, how to read tool-call traces when something goes wrong.

For teams moving past a low-code prototype, this workflow, Copilot CLI plus a platform-specific skill, a shared toolbox, clear config-to-code mapping, layered local and cloud testing, generalizes well beyond any single use case. The specific agent doesn't matter nearly as much as the discipline of keeping identity, tools, and infrastructure in separate, inspectable files from the start.

Further Reading

No comments yet

Continue reading

9 min

Azure Foundry, Zero Trust, and SASE for AI Agents

This post walks through a video session by enterprise architect Hallowell M. Longley, "Agentic AI Architecture" (youtu.be/IcEqtjrhyB0). It covers Microsoft Foundry, Zero Trust, and SASE, and how they fit together when you run AI agents at scale. The main idea is simple. The old security perimeter is mostly gone. Agents now run across many clouds, so you need one place to build and manage them, and one set of security rules that follows them. This post does not cover pricing, licensing, or setup steps. I checked the session's Foundry claims against Microsoft Learn