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, 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, 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,
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, 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 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 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.
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, 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, 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 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:,
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 on July 15, the YC-backed 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-28specification 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.