Source: https://toddschiller.com/blog/extensibility-radar-2026-07-24.html # Note This Week in Extensibility: Wasmtime enables GC and exceptions by default, WebMCP specs in-page agent APIs, the WebExtensions group commits to shipping spec text Jul 24, 2026 by [Todd Schiller](https://toddschiller.com/pages/about.html) Also posted on [LinkedIn ↗](https://www.linkedin.com/posts/tschiller_webmcp-wasm-webextensions-activity-7486464714986893323-86vR/) Week of July 17–24, 2026: Wasmtime turns on WebAssembly GC and exceptions by default, WebMCP specifies how a user's in-page agent discovers and invokes a site's tools, and the W3C WebExtensions group commits to writing normative spec text. extensibilitypluginssandboxesweb standardsWebAssemblyWebMCPWebExtensionsHubSpot The week moved extensibility work from proposal to committed output. Wasmtime turned a pair of long-incubating WebAssembly proposals on by default, the WebExtensions group agreed to start writing normative spec text instead of just triaging ideas, and WebMCP specified the two APIs a user's in-page agent needs to find and call a site's tools. ## Infrastructure: Wasmtime turns on WebAssembly GC and exceptions by default **Wasmtime 47.0.0 enabled the WebAssembly garbage-collection and exception-handling proposals by default.** The [release](https://github.com/bytecodealliance/wasmtime/releases/tag/v47.0.0), out July 20, flips both proposals on without a flag and adds bounds-checked unsafe intrinsics that account for Spectre mitigations. Wasmtime is the reference host runtime under the Wasm plugin platforms a product uses to run its customers' code, so GC-by-default widens which guest languages (e.g., Kotlin, Java, Dart, OCaml) compile cleanly to guest components. **Why it matters:** it expands the set of languages a customer can use to write plugins for a Wasm host, and the Spectre-aware intrinsics tighten the sandbox boundary that isolation depends on. ## Standards: WebMCP specs how a page's tools are discovered and invoked **WebMCP specified `getTools()` and drafted `executeTool()`, the discovery and invocation half of in-page agents.** WebMCP lets a website expose in-page tools for a user's agent to call. The [`getTools()` API](https://github.com/webmachinelearning/webmcp/pull/223), merged July 21, returns the tools a document and its descendant iframes register, with a `fromOrigins` filter and a `"tools"` permissions-policy gate, and is aimed at agents written in JavaScript that run inside the page. A companion [`executeTool()` draft](https://github.com/webmachinelearning/webmcp/pull/226), opened the same day, adds the call that runs a discovered tool with an abort signal and same-origin checks. **Why it matters:** together these let a user's own agent find and drive a web app's real functions instead of scraping the DOM. WebMCP is a Web Machine Learning Community Group draft shipping only as a Chrome origin trial (Chrome 149 through 156), so this is a single-vendor implementation of an unratified spec, not a stable or cross-vendor capability. ## Governance: WebExtensions commits to writing normative spec text **The W3C WebExtensions group drafted a division of labor and agreed to ship spec text in small iterations.** A [first-draft governance document](https://github.com/w3c/webextensions/pull/1049), opened July 23, codifies the split: exploratory and browser-specific work stays in the Community Group, while normative, public-facing spec commitments move to the chartered Working Group, and only after two or more browser vendors commit to implement. The same-day [Working Group minutes](https://github.com/w3c/webextensions/pull/1050) record a decision to shorten approval windows to about a week and land accurate-but-incomplete spec text incrementally, starting with the Alarms API. **Why it matters:** the cross-browser extension platform is shifting from incubation to normative output. The two-vendor gate keeps it consensus-driven, and the incremental-text decision is a bet that publishing partial spec beats waiting for comprehensive review. ## Applications: HubSpot opens customer-built agents in public beta **HubSpot launched Agent Hub and Agent Builder in public beta.** The [July 23 release](https://www.hubspot.com/company-news/meet-agent-hub-and-agent-builder) gives all Professional and Enterprise customers a console to build and manage AI agents. Agent Builder assembles custom agents on a single canvas in natural language via Breeze Assistant, running on existing CRM context (deal history, contact records, call transcripts) with triggers from schedules, webhooks, or third-party integrations, per the [beta announcement](https://community.hubspot.com/t/introducing-agent-hub-and-agent-builder-public-beta/153922). **Why it matters:** this is a customer-facing build-your-own-agent surface inside a widely used CRM, not a single prebuilt agent. It moves agent authoring to the end customer, though it is a public beta and no public agent marketplace is named yet. ## Also worth knowing **A W3C Web App Manifest change would let users inspect and modify shortcut URLs.** The [merged recommendation](https://github.com/w3c/manifest/pull/1221), from July 23, asks user agents to let a user see and edit an installed app's shortcut URL, motivated by shortcut URLs embedding tracking identifiers that survive clearing site data. It expands end-user control over what an installed app's deep links carry. **Kata Containers cut a 4.0.0 release.** [Kata 4.0.0](https://github.com/kata-containers/kata-containers/releases/tag/4.0.0), out July 20, is a major bump to the VM-isolated container runtime used for untrusted and customer workloads, but its release notes are boilerplate with no feature list, so what the new version changes is unconfirmed at the source. **Atlassian Forge began rolling out end-of-support messaging for Connect apps.** The [Forge changelog](https://developer.atlassian.com/platform/forge/changelog/) shows a July 24 production rollout of staggered end-of-support notices on the Connected Apps page, part of the ongoing Connect-to-Forge migration. **Two provisional URI schemes entered expert review.** A request to register [`nostr:`](https://mailarchive.ietf.org/arch/msg/uri-review/xiV_Kk249K48w-D5WuzGEzCXhdo/), filed July 23, would formalize the existing NIP-21 scheme so any client or OS can register as a handler for decentralized-social deep links; a `ust:` request was filed July 21. Both are early and under review, ahead of any IANA registration. **Vendo pitched embeddable, sandboxed feature-building for a product's own users.** In a [Show HN](https://news.ycombinator.com/item?id=48926618) on July 15, the YC-backed [Vendo](https://github.com/runvendo/vendo) positioned itself as a layer a product embeds so its users can build their own micro-apps and features on top of it, generating custom UIs, customizing components, wiring automations, and connecting external tools. User-written code runs in secure sandboxes inside the host's brand, guardrails, and API, and the open-source project integrates with agent frameworks, currently the Vercel AI SDK. ## On the radar - **July 28:** Target date for the MCP `2026-07-28` specification release candidate (stateless core, MCP Apps for server-rendered UIs, and a Tasks extension). - **July 30:** Next W3C WebExtensions Community Group call; the Alarms API is the first target for detailed spec text. --- *This Week in Extensibility is curated by Todd Schiller. Research, drafting, and fact checking are AI-assisted.* More on - [`#extensibility`](https://toddschiller.com/tag/extensibility.html) (19) - [`#plugins`](https://toddschiller.com/tag/plugins.html) (19) - [`#sandboxes`](https://toddschiller.com/tag/sandboxes.html) (19) - [`#web standards`](https://toddschiller.com/tag/web-standards.html) (19) - [`#WebAssembly`](https://toddschiller.com/tag/webassembly.html) (6) - [`#WebMCP`](https://toddschiller.com/tag/webmcp.html) (17) - [`#WebExtensions`](https://toddschiller.com/tag/webextensions.html) (7) - [`#HubSpot`](https://toddschiller.com/tag/hubspot.html)