CubePlex is now open source. The source is available on GitHub under the Apache-2.0 license, including the backend, web application, deployment assets, and product documentation.

There is a simple test for whether an agent has moved from a personal tool into a team workflow: can someone else rerun a successful AI workflow without reconstructing it from chat history and one person's memory? Agents can already write code, research a topic, process files, and call external tools. The harder problem is increasingly how to keep that work usable after the first run.

CubePlex is an open-source workspace built for managed agents. It brings conversations, team members, skills, memory, MCP tools, and isolated execution environments into one collaborative space, so agent work can be inspected, continued, and run again.

Agent Plugins launched publicly on August 6, 2026, as an open, vendor-neutral standard. Its initial Technical Steering Committee has five Core Maintainers affiliated with Amazon, Cursor, Microsoft, OpenAI, and Vercel. Jonathan Hefner of Vercel serves as Lead Core Maintainer.

The governance roles belong to individuals rather than reserved company seats, and no single vendor may control a majority of Core Maintainers. It is more precise to describe Agent Plugins as a community-governed specification started by maintainers from those five companies.

Version 1.0.0 is currently a Working Draft. Every plugin has a plugin.json manifest, with Agent Skills under skills/ and MCP server configuration in mcp.json. Reverse-domain extension namespaces let individual clients add behavior without changing the portable core.

The specification addresses fragmented plugin formats across Agent clients. Authors previously had to rearrange the same Skills and MCP configurations for different client directories and configuration models. Agent Plugins provides one directory structure, schema set, and loading contract that compatible clients can share.

Authentication remains client-managed. The draft defines no OAuth configuration or portable credential-reference fields. Authorization discovery, user interaction, and credential storage for remote MCP servers are also handled by the client. That is a reasonable boundary for a package format, but it leaves an important product workflow outside the portable contract.

Skills and MCP servers do different jobs. A Skill tells an Agent how to complete a task, while MCP connects it to external systems. A plugin can deliver both, yet the user may still face separate CLI logins, OAuth grants, and API keys. Installing the components does not make their connections usable.

Cloud agent platforms commonly use one of two architectures. The first puts an existing harness such as Claude Code, Codex, or OpenCode inside a sandbox. VibeKit and LiteLLM Agent Platform represent this approach, while Buzz also reuses these harnesses. The second keeps the agent loop in the control plane and uses sandboxes only for execution. Claude Managed Agents and OpenHands use this boundary, while products such as Manus and Perplexity Computer also appear closer to centrally scheduled execution. The first architecture fits automation with a clear start and finish. The second is a better fit for Managed Agents that may run for weeks or months, wait for events, and serve multiple users.

Agent tools have made it easy to turn a request into action. That is useful, but it also creates a new operational question: where does the work live after the conversation ends?

For a person, a short-lived chat can be enough. For a team, it is rarely enough. Work has inputs, constraints, tools, approvals, outputs, and a record of what happened. When those parts are scattered across chat threads, browser tabs, and private accounts, the team cannot confidently reuse or review the result.

OpenSandbox and CubeSandbox both provide isolated code execution environments for agents, but they optimize for different infrastructure models. OpenSandbox manages sandboxes through Kubernetes resources and scheduling. CubeSandbox ships an integrated runtime stack from its control plane down to KVM MicroVMs, with an emphasis on high-concurrency creation, execution-state snapshots, and fast recovery.

Self-hosting is often described as an installation choice. For agent systems, it is more accurately an operating model.

Where an agent runs determines where its credentials live, which data it can reach, how its network access is governed, and who can inspect its execution. Those are not details to add after the workflow is useful. They are part of the workflow from the beginning.

The first useful agent interaction often looks deceptively simple. Someone asks for help, the agent retrieves context, runs a tool, and produces an answer or artifact.

The next question is more important: can the team run that process again without reconstructing it from memory?