CubePlex Blog

DeerFlow 2.0 and CubePlex are both general-purpose agent environments. Both support long-term memory, Skills, MCP, Sandboxes, Sub-agents, and messaging integrations. Both let users research, write, code, and work with files from one conversation instead of building a separate App for every use case. Their open-source repositories are available at bytedance/deer-flow and cubeplexai/cubeplex, with usage and deployment guidance in the DeerFlow Documentation and CubePlex Documentation.

The difference starts with who owns the Agent. DeerFlow gives each user a personal Agent environment. After signing in, a user sees their own Agents, Projects, conversations, memories, Skills, and files. CubePlex places the Agent inside a Workspace. An organization creates the Workspace, adds members, configures the Agent, and decides which Skills, MCP servers, and credentials the team can use.

If OpenClaw represents a long-running desktop Agent for one person, a CubePlex Workspace is the team version of that product shape. The Agent has a stable name and way of working, knows the project context the team has confirmed, and uses team-approved Skills and MCP connections. It can work with organization accounts, project accounts, or each member's own account. Members can reach it from the web, Slack, Feishu, or other channels. Private chats, group conversations, and Topics can keep separate conversation and execution contexts, while the Agent's identity, team knowledge, and tool configuration remain with the Workspace. When a member leaves, the Agent and the team's accumulated working state remain with the team.

Agent products are taking two different approaches to how people get work done.

Dify starts with a defined scenario. A team identifies a problem such as customer support, knowledge Q&A, contract review, or report generation, then configures the model, Workflow, Knowledge, and tools for that problem. The result is published as a web app, API, embed, or MCP service. Users choose an App and work within the capabilities it was built to provide. Dify's source code and usage guides are available on GitHub and in its documentation.

CubePlex starts with a long-lived Agent. A person or team keeps using the same Agent in a Workspace and gives it different kinds of work over time. The Agent retains its role, memory, Skills, and MCP connections, and can operate a durable computer environment when a task requires one. Instead of switching among Apps for different scenarios, users return to an Agent that becomes familiar with how the team works. CubePlex also provides its source code and product documentation.

That difference shapes how the two products organize capabilities, state, and collaboration.

QM (Quartermaster) is YC's open-source, self-hosted multiplayer agent harness. It places people, Slack channels, groups, and projects in scopes, using each scope as an agent work environment and permission boundary. CubePlex is an open-source Agent Workspace for teams: it first defines a long-lived Workspace Agent, then lets Web, Slack, Discord, Microsoft Teams, Feishu/Lark, DingTalk, WeCom, and other entry points determine the conversation, identity, and execution boundary for a run.

The distinction changes everyday use. One model is suited to operating many independent agent computers under a company's permission and runtime system. The other is suited to keeping one team agent consistent across entry points without mixing private conversations, credentials, or execution environments.

YC open-sourced QM (Quartermaster) in July 2026. Its launch note describes starting with a Ruby agent loop that could reach internal data, adding crons and webhooks, and later giving individual employees more than 50 Hermes personal agents. Those agents were flexible, but managing the fleet became difficult.

QM is the result of that experience. It aims to retain the flexibility of a personal agent while giving an organization a way to manage models, permissions, and the runtime. Slack direct messages, channels, group DMs, and projects resolve to different scopes; collaboration happens inside those scopes rather than by handing one person's environment to the entire company.

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.