Microsoft has opened the GitHub Copilot agent harness to external developers through the Foundry Agent Service, now in public preview. The managed harness supplies sandboxed execution, reusable skills, MCP integrations, and sub‑agent coordination, while Microsoft retains control of the runtime environment. For AI, cloud, DevOps, and security engineers this means a shortcut to building autonomous agents, but also new constraints around model choice, resource limits, and pricing.
What changed: Copilot harness public preview
The harness, previously internal to Copilot products, is now offered as a managed service. It supports Copilot Code, Copilot Studio, GitHub Copilot, the CLI, and VS Code. Developers select a supported model from the Foundry catalog, define instructions and tools, and let Microsoft run the agent. Configuration is expressed in a markdown‑based skill and an azure.yaml file that specifies model deployment, tools, and the harness type (microsoft_copilot_preview). Deployment uses azd deploy --all and agents are invoked via the Azure Developer CLI. All supporting files can be kept in source control alongside application code.
Architectural and operational implications
The harness abstracts away the underlying compute, providing built‑in sandboxing and policy enforcement. However, the choice of harness is immutable once a prompt agent is created; it cannot be switched in later versions. Microsoft allocates CPU, memory, and idle‑time limits, reducing the engineer’s ability to fine‑tune the execution environment. Model selection is limited to those deployed through Foundry; custom models cannot be imported. Teams needing full control can opt for Foundry’s hosted agents, which allow custom frameworks while still using Microsoft‑hosted infrastructure.
Long‑running resilience is now generally available for hosted agents, enabling recovery from interruptions in tasks that span hours or days. This feature is relevant for workflows that involve extensive data processing or multi‑step reasoning.
Security and governance considerations
Built‑in sandboxing isolates agent execution, and the harness tracks model and tool calls while enforcing configured policies. Skills bundle instructions, scripts, and resources, and MCP integrations require explicit authentication and approval, adding a layer of access control. Because the environment is managed by Microsoft, engineers have limited visibility into low‑level runtime configurations, which may affect threat modeling and compliance assessments.
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
- Evaluate whether the managed harness aligns with your performance and customization requirements, given the fixed CPU/memory caps and inability to change the harness type after creation.
- Plan for source‑controlled skill and
azure.yamldefinitions to keep agent configurations versioned with application code. - Assess the impact of using only Foundry‑provided models; if you need proprietary models, consider the hosted‑agent path instead.
- Incorporate the sandboxing and policy enforcement capabilities into your security review, but account for reduced low‑level control over the execution environment.
- Monitor the free‑preview window (until 1 December 2026) and the announced compute pricing ($0.0994 per vCPU‑hour, $0.0118 per GiB‑hour, with regional variations) to forecast operational costs.
