Three separate stories out of the developer tooling world this week point to the same underlying theme: infrastructure that used to be locked to a single vendor is being pried open into shared, interoperable standards. Here’s what happened and why it matters.

AI agents get a shared plugin format

AWS, Microsoft, OpenAI, Anysphere, and Vercel have jointly published “Agent Plugins 1.0.0,” a spec that lets AI agent “skills” and MCP (Model Context Protocol) server configurations be defined once and reused across different agent platforms. Google has also announced support for the format.

This matters because the AI agent ecosystem has exploded with proprietary conventions: each vendor’s agent framework — whether from OpenAI, Anthropic, Google, or Microsoft — has tended to define its own way of describing what an agent can do and how it connects to external tools via MCP servers. That fragmentation forces developers to rewrite the same integration logic for every agent runtime they want to support.

Agent Plugins aims to do for AI agents what OCI did for containers: create a lingua franca so a “skill” (a packaged capability an agent can invoke) and its associated MCP server setup can be authored once and dropped into Claude-based tools, Copilot, OpenAI’s agent stack, AWS’s agent offerings, or Google’s ecosystem without modification. Given that five major agent vendors plus Google are aligned on version 1.0.0 rather than a draft proposal, this looks less like a speculative RFC and more like an emerging de facto standard — the kind of moment where an ecosystem quietly decides on its plumbing before most developers have even noticed there was a problem to solve. Expect tooling (skill marketplaces, MCP server directories, agent SDKs) to start assuming this format as a baseline fairly quickly, given the backer list.

Mitchell Hashimoto starts over, again

Mitchell Hashimoto, co-founder of HashiCorp (Terraform, Vault, Consul) and more recently the independent developer behind the terminal emulator Ghostty, has founded a new company called Superlogical. His own announcement frames the starting point modestly — a terminal multiplexer — while gesturing at something much bigger:

We’re going to begin by building a terminal multiplexer. The entire vision is much larger.

A terminal multiplexer (think tmux or screen) lets you split a terminal into multiple panes and sessions that persist independently of your SSH connection or terminal window. It’s unglamorous, foundational infrastructure — exactly the kind of layer Hashimoto has repeatedly chosen to rebuild from scratch (Vagrant reimagined VM provisioning, Terraform reimagined infrastructure state, Ghostty reimagined the terminal emulator itself).

What’s notable here is the pattern, not just the product. Hashimoto has built a career out of picking widely-used but rarely-reexamined developer tools and rewriting them with modern performance and UX expectations in mind. Given his stated ambition — a “multiplexer… for any kind of work,” not just terminal sessions — Superlogical may be aiming at something closer to a general session/workspace orchestration layer than a tmux clone. It’s early, so concrete details are thin, but given his track record, this is worth watching rather than dismissing as another side project.

vlt reaches 1.0 and starts selling registry hosting

vlt technology’s npm-compatible package manager, vlt (pronounced “vōlt”), has hit version 1.0. Alongside the release, the company has launched paid hosting for its registry software, “vsr,” which can act as either an npm mirror registry or a fully private registry.

npm’s dominance as JavaScript’s package registry has come with well-documented pain points: supply-chain attacks via typosquatting and compromised maintainer accounts, slow or inconsistent install performance, and a lack of first-party tooling for organizations that want a private, audited mirror of their dependency tree. vlt positions itself as a security-first alternative that’s still compatible with the existing npm package ecosystem — meaning teams don’t have to abandon their current dependencies to adopt it, just swap out the client and, optionally, the registry backend.

The addition of hosted mirror and private registry services is the more consequential part of this announcement for teams evaluating adoption. A drop-in CLI replacement is a nice-to-have; a hosted, security-focused mirror registry is what actually lets an engineering org reduce its exposure to npm supply-chain incidents without standing up and maintaining that infrastructure themselves. Founder Darcy Clarke’s announcement frames 1.0 as the point where vlt is ready for that kind of production reliance, though as with any npm alternative, the real test will be whether package maintainers and CI pipelines adopt it widely enough to make the mirror useful at scale.

The common thread

What ties these three stories together is a broader shift in developer tooling: standardization efforts (Agent Plugins) and infrastructure rebuilds (Superlogical, vlt) are both responses to ecosystems that grew fast and messy. Whether it’s AI agents drowning in incompatible skill formats, terminal workflows that haven’t fundamentally changed in decades, or a package registry carrying two decades of security debt, the pattern is the same: once an area gets popular enough, someone rebuilds the plumbing — and this week, several someones did it at once.