Microsoft Ships Copilot Harness to Run Multi-Step AI Agents Without Infrastructure

retained text

Microsoft Ships Copilot Harness to Run Multi-Step AI Agents Without Infrastructure
Microsoft's new managed agent harness in Foundry handles orchestration, tools, context, and sandboxing so developers can skip rebuilding the execution layer.
- Microsoft launched the Copilot harness in Foundry Agent Service in public preview, a managed agent execution layer.
- Handles the agent loop, sandbox, working context, tool calls, files, and subagent delegation for you.
- Agents are defined declaratively via YAML plus Markdown skill files, deployable through azd, the Foundry portal, or VS Code.
- Supports Foundry tools and MCP tools with explicit auth and approval configuration.
- Long-running resilience for hosted agents hits GA, enabling restart-from-checkpoint for multi-hour workflows.
- Billing starts December 1 at $0.0994 per vCPU-hour and $0.0118 per GiB-hour of sandbox memory.
Microsoft has released the Copilot harness in Foundry Agent Service as a public preview, according to its preview announcement. Developers define an agent and choose a supported Foundry model; Microsoft runs the agent loop, working context, tool coordination, file handling, sandboxed code execution, and recovery logic.
The managed execution layer comes from the harness built by the GitHub Copilot engineering team and now shared across Microsoft products. It reduces the infrastructure required for multi-step agents while leaving developers responsible for instructions, skills, tool access, evaluations, durable state, and application-specific safeguards.
Inside the managed loop
The public preview combines four components that teams commonly build for themselves:
- Reusable skills: Packaged instructions, scripts, and supporting resources that agents can apply across tasks.
- Connected tools: Supported Foundry tools and Model Context Protocol tools, with explicit authentication and approval controls.
- Execution and delegation: File and code operations inside a managed sandbox, plus bounded tasks delegated to built-in subagents.
- Versioned definitions: Agent configuration authored in Foundry or stored with application code in source control.
During a run, the harness maintains working context and coordinates model and tool calls within configured limits and policies. Developers still need to specify the desired outcome, grant appropriate permissions, test failure cases, and evaluate the resulting behavior.
Authoring is YAML plus Markdown
Each skill is a Markdown file with YAML frontmatter under skills/. The agent definition lives in azure.yaml, where developers select the model deployment, skills, tools, and harness:
research-brief:
  host: azure.ai.agent
  kind: prompt
  harness:
    type: microsoft_copilot_preview
  model: ${MODEL_DEPLOYMENT_NAME}
  skills:
    - research-brief-skill
  tools:
    - type: web_search
    - type: code_interpreter
The preview version of Azure Developer CLI provides the direct deployment path. Run azd deploy --all to deploy the project, then azd ai agent invoke to invoke the agent. Developers can also author agents in the Foundry portal, the Foundry Toolkit for Visual Studio Code, or the Microsoft Foundry plugin and Skill in the GitHub Copilot app.
Recovery needs durable checkpoints
Microsoft has separately made long-running resilience for hosted agents generally available, with implementation details in its resilience guide. The feature targets work that may continue for hours or days and encounter infrastructure interruptions.
When Foundry detects an interruption, it restarts the work with the original input. Application code must persist checkpoints and intermediate results so the agent can identify completed steps and resume safely. Workflows that modify external systems also need idempotency controls to prevent repeated messages, transactions, file writes, or API calls after a restart. Conversation history does not provide a complete record of in-progress work.
Pick the execution tier
Foundry now offers three execution approaches with different levels of control and operational responsibility:
Preview constraints and costs
- The harness must be selected when an agent is created.
- Existing agents remain unchanged, and an agent cannot switch harnesses after creation.
- Foundry controls the sandbox CPU, memory, and idle settings.
- Model inference and separately billed tools incur their usual charges during the preview.
The harness is available through the Foundry portal and the preview Azure Developer CLI. Microsoft says consumption billing begins December 1, 2025. Harness runtime usage remains free before that date, excluding model and tool charges. After billing starts, sandbox compute costs US$0.0994 per vCPU-hour and US$0.0118 per GiB-hour of memory.
Early design partner Confluence Technologies reported deploying a solution in under a week, although that vendor account does not provide a comparative benchmark. The practical tradeoff is clearer: teams can transfer agent-loop and sandbox operations to Microsoft, but they retain ownership of agent behavior, security boundaries, persisted state, external side effects, and evaluation.

document fetched 2026-10-29 03:02