The socket, not the surface: the Agent Host Protocol opens the IDE the week MCP reaches the Office apps
Edition 010 was about where the agent runs. This week the question moved to what it plugs into. VS Code 1.129 moved agent execution out of the editor process and into a dedicated Agent Host, reached through the Agent Host Protocol, an open MIT-licensed spec with SDKs in five languages that runs Copilot, Claude, and Codex as equals. On the same days, MCP-built agents appeared in the web versions of Word, Excel, PowerPoint and Outlook, federated Copilot connectors arrived that query external systems with the user's own credentials and no org-wide index, Agent Skills reached a stable API in Python, and the Microsoft 365 admin center became the place where prompts, agents, and agent security are governed. The pattern underneath all of it: Microsoft is standardizing the socket rather than trying to own the surface.
This week's thread: standardize the socket, do not fight for the surface
There is a version of this week that reads as five unrelated release notes. There is a better reading. Look at what each one actually did to an interface. VS Code stopped running agents inside its own process and started speaking a published protocol to a separate host, then released that protocol under MIT with its own repo and SDKs in Rust, TypeScript, Kotlin, Go, and Swift. The harnesses it hosts include Anthropic's Claude and OpenAI's Codex alongside Microsoft's own Copilot, which is a strange thing to build if your goal is to keep developers inside your agent. MCP, a protocol Microsoft did not invent, became the way agents show up inside Word, Excel, PowerPoint and Outlook on the web. Federated Copilot connectors went further and gave up the index entirely, querying the source system at runtime with the user's own credentials so the permissions never get copied anywhere. Agent Skills reached a stable API in Python, the same portable capability package edition 010 watched land in .NET. Every one of those is Microsoft defining a connection point and then declining to close it. It is the architecture @Bas Brekelmans has been describing for a year, multi-model and protocol-first by design rather than by concession, now showing up in five separate release notes in the same week. The strategic read is that when the surfaces multiply faster than anyone can own them, the durable position is the socket everything plugs into. Satya Nadella made the argument out loud on Thursday, warning in Fortune that enterprises are paying twice for AI, once in tokens and again by handing their proprietary know-how to the model makers, and arguing for orchestration layers that let a company switch vendors. It is a notable thing to say from inside a company with billions committed to OpenAI and Anthropic. Read the week's releases as the engineering expression of that same argument.
Signal of the week
VS Code 1.129 moves agents out of process and opens the Agent Host Protocol
On July 15, VS Code 1.129 shipped a rearchitecture of how the editor runs AI coding agents. Agent harnesses no longer execute inside the main VS Code process. They run in a dedicated process called the Agent Host, which VS Code communicates with through the Agent Host Protocol, a JSON-RPC based specification. The release notes name Copilot, Claude, and Codex as the harnesses it runs. AHP is not VS Code-internal shorthand: it is a Microsoft-owned open specification with its own MIT-licensed repository and published SDKs in Rust, TypeScript, Kotlin, Go, and Swift, with VS Code serving as the reference implementation. The same release brought a redesigned Agents window that pulls the editor and detail area into one docked pane with a shared tab bar, the ability to prefix a chat message with an exclamation mark to run its contents as a terminal command, and bring-your-own-key model selection when running the Copilot harness on the agent host. The Agents window redesign is flagged experimental. The Agent Host architecture is not.
Why it matters
Process isolation sounds like an implementation detail until you consider what it makes possible. An agent that runs in its own process can be resource-limited, sandboxed, restarted, and observed independently of the editor, which is the difference between an agent you tolerate on a developer laptop and one a security team will approve across an org. But the bigger signal is the licence. Microsoft could have kept the interface between VS Code and its agents private and made Copilot the only comfortable harness. Instead it published the protocol, shipped SDKs in five languages, and used the release notes to name two competitors as first-class citizens. That is a bet that the value sits in the editor and the protocol rather than in locking the agent to a vendor. For anyone advising on tooling standards, this changes the shape of the question. The choice of coding agent is now less architecturally binding than it was a week ago, because the host that runs it is speaking a documented protocol that anyone can implement. @Burke Holland's beat is the place to watch this land in practice, because the gap between a published protocol and a workflow developers actually adopt is usually where these things live or die. Before you standardize your organization on a single coding agent, look at whether the AHP layer lets you keep that decision reversible.
1The other IDE moved the same week
VS Code was not alone. Visual Studio shipped its July update a day earlier, with a set of changes that point in the same direction: agents that are configurable at the organization level and measurable at the token level.
Visual Studio 2026 July update adds org-level Copilot instructions and token usage alerts
The July 14 Visual Studio 2026 update brought several agent-facing changes at once. GitHub Copilot now ships with built-in .NET and Azure skills authored by Microsoft experts, so agentic workflows start from domain guidance rather than a blank context. A refreshed Copilot Usage window gives real-time tracking of consumption with proactive alerts as developers approach token limits. GitHub organization owners can now set custom instructions that apply automatically to every team member's Copilot, rather than relying on each developer to configure their own. A new Agent option in Copilot Chat, built on the GitHub Copilot SDK, is designed to complete tasks in fewer turns with shorter responses. And a Review Selection action lets a developer highlight code, right click, and get targeted Copilot review feedback without opening a formal review workflow.
Why it matters
Two of these matter more than the headline features. Organization-level custom instructions turn Copilot behaviour into a governed setting rather than a per-developer preference, which is exactly what a team needs before it can claim its coding standards are actually enforced rather than merely documented. The usage window matters because it is the first practical answer to a question that has been awkward since consumption pricing arrived: developers had no way to see the meter running until the bill showed up. Giving them proactive alerts moves cost awareness to the point of use. If you run Copilot across a team, these two settings are worth an afternoon now, because both are the kind of control that is far easier to establish before habits form than after.
2MCP reaches the apps, and the connector gives up its index
Two entries in the July 15 Microsoft 365 Copilot release notes deserve to be read together. One puts MCP agents inside the Office apps. The other quietly changes how Copilot reaches data it does not own.
MCP-built agents become available in the Office web apps
The July 15 Microsoft 365 Copilot release notes state that agents built with the Model Context Protocol are available in Word, Excel, PowerPoint, Outlook, and Catalyst. The entry is tagged for web only, so this is the browser versions of those apps rather than the Windows, Mac, or mobile clients. As with everything on that page, the rollout reaches a subset of users in a tenant before it reaches all of them. One honest caveat worth flagging: Catalyst is Microsoft's own wording in the release note, but it is not a surface Microsoft documents anywhere else in the Copilot app or requirements pages, so treat it as named but not yet explained.
Why it matters
The significance is which protocol got there. An MCP agent is not a Microsoft-specific artifact, so the same server that backs an agent in Claude or a coding agent in the terminal can now surface inside the document where the work actually happens. For a partner practice, that changes the build calculus: an MCP server stops being an integration for one surface and becomes an asset that reaches several, which is a much easier investment to justify to a client. Two practical notes before you promise anything. It is web only for now, so confirm your users are actually in the browser versions before you scope a rollout. And the underlying protocol is about to change: the next MCP specification ships July 28 and drops the session and the initialize handshake, so anything you build in the next few weeks should be checked against the release candidate rather than the current stable spec.
Federated Copilot connectors query the source system with the user's own credentials
The same July 15 release notes introduced federated Copilot connectors in the Microsoft 365 admin center Connectors tab. These are MCP-based connectors to external and line-of-business systems, and their defining property is what they do not do: they perform no organization-wide indexing. Instead they authenticate as the individual user at query time and retrieve results live from the source system, so the source system's own permissions decide what comes back. This is a departure from the established Copilot connector model, where content is ingested into an organizational index ahead of time and permissions are mapped across during that ingestion.
Why it matters
This is the most architecturally interesting thing Microsoft shipped this week, and it arrived as a bullet point. Every oversharing incident in a Copilot deployment traces back to the same root: a copy of the data exists somewhere with permissions that drifted from the source. A federated connector removes the copy. There is no index to get stale, no permission mapping to go wrong, and nothing to purge when someone changes role. The trade is real and you should price it honestly: live queries are slower than an index, you inherit the source system's availability and rate limits, and you lose the semantic ranking that indexing buys you. But for the systems that make security teams say no, the HR platform, the case management system, the regulated record store, this is a materially easier conversation than anything that was available last week. If you have a Copilot deployment stalled on a data governance objection, look at whether a federated connector routes around the objection entirely.
3The skill layer finishes the set
Edition 010 covered Agent Skills reaching a stable API in .NET. Eight days later the other half landed.
Agent Skills for Python reaches a stable, production-ready API
On July 15, Agent Skills for Python in Microsoft Agent Framework was declared stable and shipping. Skills are reusable packages of domain expertise, instructions, reference documents, and scripts, that an agent loads only when a task calls for them. The announcement is explicit that the core skills API carries no experimental gate and can be relied on in production. It pairs with the .NET release from July 7 that edition 010 covered, which means the same portable capability unit is now production-stable in both first-party SDKs. Note the precise wording: Microsoft says stable and production-ready rather than generally available, which is a slightly different commitment and worth repeating accurately.
Why it matters
The interesting part is not Python parity, it is that the skill keeps showing up as the unit everything converges on. It is the packaging format in Copilot Studio, the architecture underneath the Dataverse coding-agent plugin, and now a stable API in both Agent Framework SDKs. When the same primitive appears independently across the low-code surface, the data platform, and the pro-code framework, that is the platform telling you what to build against. For a team deciding how to package agent logic so it survives a tooling change, @Evan Mattson's SDK now gives you the same answer on both sides: author the capability once as a skill, and let it move across surfaces instead of being rewritten for each one.
4The admin center becomes the agent's front desk
Prompts and agents both become tenant-managed objects on the same day
Two July 15 release note entries move agent governance into the Microsoft 365 admin center. Administrators can now build prompt collections tailored to their company's needs and publish them tenant-wide through the Copilot Prompt Gallery, managed from the admin center and rolling out on Windows and web under roadmap item 486695. Separately, customers can submit agents built in Agent Builder to the Agent Store under a Built by your org section, after admin review and approval in the Microsoft 365 admin center, under roadmap item 557173. The prompt and the agent are now both objects an organization curates, reviews, and publishes centrally.
Why it matters
The Built by your org detail is the part to notice, because it establishes an internal distribution channel with a review gate rather than a free-for-all. That is the difference between shadow agents proliferating across a tenant and a small catalogue somebody owns. Taken with the prompt gallery, it means the two things that most determine whether Copilot produces useful output, the prompt and the agent, stop being individual artifacts and become curated organizational assets. For anyone running an adoption programme, this is the missing distribution layer. The reason good internal prompts never spread was that there was no supported way to publish them, and the reason agent sprawl happens is that there was no supported way to review and promote the good ones. Both now exist. The work this creates is editorial rather than technical: someone has to own the catalogue, and that role probably does not exist on your client's org chart yet.
5The agent gets a security product
Security for Microsoft Agent 365 with Defender reaches general availability
In July 2026, Microsoft Defender's protection for AI agents reached general availability. With a Microsoft Agent 365 licence, Defender provides discovery, security posture assessment, threat detection and investigation, and real-time protection for the AI agents running in a tenant. The Defender XDR what's new page is organized by month rather than by day, so this is dated to July 2026 without a precise release date.
Why it matters
Discovery is the word that matters. Threat detection assumes you know what you are protecting, and the honest state of most tenants right now is that nobody has a full list of the agents running in them. An agent inventory that Defender builds rather than one your client assembles by hand is the first practical answer to a question that has been asked in every governance conversation for a year. It also completes the pattern edition 009 started tracking, when Defender handed agent protection to Agent 365 on July 1: the agent is no longer a workload defended by whatever protects the app around it, it is a first-class object with its own security product and its own licence line. That licence line is the thing to raise early, because Agent 365 is the prerequisite, and discovering that during a security review is worse than discovering it during scoping. @Rod Trent's corner of the stack is now where the agent perimeter actually lives.
Voices to follow
- Microsoft EVP - Copilot, Agents & PlatformCharles Lamanna
Executive Vice President for Copilot, Agents, and Platform at Microsoft. He owns the strategy behind Copilot Studio, Agent 365, and the Power Platform, so when the agent stack's direction shifts, it usually shifts because of a decision his org made.
Microsoft EVP - Copilot, Agents & Platform - Microsoft Partner Director - Foundry Agent ServiceJeff Hollan
Partner Director of Product at Microsoft, leading the Foundry agent platform: Agent Service, the Agent Framework, and the SDKs. The clearest source on how agents actually go from prototype to a hosted production runtime.
Microsoft Partner Director - Foundry Agent Service + Agent Framework - Microsoft Principal Cloud Advocate - Power Platform + agentsDaniel Laskewitz
Principal Cloud Advocate at Microsoft, ex-Power Platform MVP and co-founder of Forward Forever. One of the clearest voices on multi-agent systems and Power Platform governance - the bridge between the maker community and the product teams.
Microsoft Principal Cloud Advocate - Power Platform governance + agents - Microsoft CVP - Security, Compliance, Identity & PrivacyVasu Jakkal
Corporate Vice President for Microsoft Security. Defender's AI agent posture risk, the Agent 365 security integration and the wider security-for-AI story all ship out of her organisation.
Microsoft CVP - Security, Compliance, Identity & Privacy - Copilot Studio MVPLisa Crosbie
6x Microsoft MVP, Practical AI for Business with Copilot and Agents at Barhead. Calm, hands-on voice on production-grade agent design - the one to follow when you want patterns you can ship, not just demo.
6x Microsoft MVP - YouTuber + International Speaker - ~21K followers - Microsoft Software Engineer - CoworkBas Brekelmans
Software Engineer at Microsoft, started the Copilot Cowork project and previously CTO of Copilot Studio. The clearest voice on why Microsoft chose multi-model, MCP, and A2A architecture across the agent stack.
Microsoft Software Engineer, Cowork - ex-CTO Copilot Studio - Microsoft Principal PM - Copilot Studio (Power CAT)Henry Jammes
Principal Program Manager for Copilot Studio on the Power CAT team at Microsoft. Deep on agent-building mechanics, governance, and the release roadmap - a first-party source on what Copilot Studio can actually do.
Microsoft Principal PM - Copilot Studio (Power CAT) - Microsoft Principal Cloud Developer Advocate - AISeth Juarez
Principal Cloud Developer Advocate at Microsoft on AI. One of the most watchable explainers of Foundry, the Agent Framework, and GitHub Copilot for developers - deep technical content that stays accessible.
Microsoft Principal Cloud Developer Advocate - AI
Coming up
- Tuesday July 21, 2026, 10am PT · Claude in Microsoft Foundry: building agents for production, a live session with Caroline Matthews of Anthropic and Keiji Kanazawa of Microsoft. Worth noting the GA itself is already behind us: Claude models went generally available in Microsoft Foundry on June 29.
- July 28, 2026 · The next MCP specification ships. Version 2026-07-28 removes the initialize and initialized handshake and drops the Mcp-Session-Id header along with the protocol-level session, making the transport stateless, and requires clients to validate the iss parameter on authorization responses per RFC 9207. The current stable specification is still 2025-11-25, so anything you ship against MCP this month should be checked against the release candidate.
- August 2, 2026 · Core EU AI Act provisions take effect. The Digital Omnibus postponed the high-risk dates, not these: general-purpose AI, prohibited-practice, and core transparency rules still start on schedule.
- September 2026 · SPFx 1.24 and the SharePoint Framework CLI reach general availability, with SharePoint Copilot Apps as the supported path for bringing interactive SPFx UI into the Microsoft 365 Copilot canvas.
- November 10, 2026 · .NET 8 and .NET 9 reach end of support. Plan the move to .NET 10 LTS now, especially for any agent, Agent Framework, or Foundry workload pinned to the older runtimes.
This week's question
Microsoft spent this week publishing its interfaces and centralizing its controls. The protocol that runs your coding agent is now MIT-licensed with SDKs in five languages and treats Claude and Codex as equals. The protocol that puts agents in your Office apps is one Microsoft did not invent. Meanwhile the catalogue that decides which agents your organization can use, and the product that watches them, live in the Microsoft 365 admin center. So two questions for Monday. The practical one: if the socket is genuinely open, how much of your current agent architecture is actually portable, and have you ever tested that assumption rather than assumed it? And the harder one: Satya Nadella spent Thursday warning enterprises not to hand their know-how to model makers and to keep an orchestration layer they control. If you take that advice seriously, does an open protocol with a centralized control plane count as the orchestration layer you own, or as the most comfortable place to stop looking?
Get Agentic Weekly in your inbox
Every Monday morning. Unsubscribe any time.