docs(blog): draft managed agents architecture article

blog/2026-08-06-agent-plugins-authentication-gap.mdx

@@ -0,0 +1,65 @@
+---
+slug: agent-plugins-authentication-gap
+title: The Authentication Gap in Agent Plugins
+description: Agent Plugins standardizes how Skills and MCP servers are packaged, while clients still own connection flows, credential injection, and permission management.
+authors: [xfgong]
+tags: [Agent Plugins, MCP, Agent Skills, Authentication]
+image: /img/blog/agent-plugins-authentication-gap-cover-en.webp
+---
+
+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.
+
+<!-- truncate -->
+
+## Authentication for Skill-invoked CLIs
+
+Many Skills invoke command-line tools. A tool may require a browser login, an API key, an environment variable, a credentials file, or an existing session in the operating system keychain. Agent Plugins defines how a client discovers `SKILL.md` and its files, but it does not define how those tools request a connection from the user.
+
+Developers running a plugin for themselves can finish authentication in a terminal. A web-based Agent platform needs to show which service is requesting access, which account will be used, and how that connection can later be revoked. Sending the user to a provider-specific login command breaks that flow. Pasting a secret into chat is riskier because the execution environment and model context may see a credential they do not need.
+
+A GitHub plugin might contain both a Skill that invokes `gh` and a GitHub MCP server. They access the same service through different authentication paths. The package does not tell a platform whether they can reuse one user connection or which minimum permissions each component needs.
+
+## Each service keeps its authorization boundary
+
+Presenting every connection through one interface is useful. Sharing one access token across the plugin usually is not. GitHub, Linear, AWS, and internal services can use different authorization and resource servers.
+
+The MCP authorization specification requires an HTTP MCP server to advertise its authorization server through Protected Resource Metadata. The client must include the target MCP server as the resource when requesting a token, and the server must validate the token audience. A token issued for one MCP server cannot be sent to another server or passed through to an upstream API.
+
+The platform can unify the **connection flow**. A user can see which services a plugin needs, choose accounts, approve permissions, and later revoke an individual connection. Behind that interface, the platform retains separate least-privilege credentials for each service.
+
+## The boundary of Agent Plugins v1.0.0
+
+Agent Plugins v1.0.0 defines two portable component types. Skills live under `skills/`, and MCP configuration lives in `mcp.json`. MCP servers can use stdio, Streamable HTTP, or legacy HTTP+SSE transports.
+
+The draft treats configured HTTP headers and stdio environment values as visible package data and prohibits embedded credentials. It defines no OAuth configuration or portable credential reference. Clients can implement authentication in their own extensions, but those extensions are outside the cross-client contract.
+
+The project's non-normative Future Considerations document names this gap directly. It lists possible future work for secret declarations, client-mediated injection, isolation between plugins, credential rotation, and revocation. None of those items is committed to a future release.
+
+## The connection contract platforms still need
+
+Agent platforms still need their own connection contract. An MCP server or Skill should be able to declare the required service, target resource, and minimum permissions. The client can map that declaration to OAuth, enterprise workload identity, a managed vault, or an approved local connection. Credentials should remain outside the plugin package.
+
+For a command-line tool, the client can inject a short-lived token only into the subprocess that needs it. A local credential broker could instead exchange a task-bound authorization for a provider token. The Agent receives temporary access for the current operation without gaining access to the underlying credential store.
+
+One user-visible connection could then serve an approved MCP server and CLI while the underlying tokens retain separate audiences, scopes, and expiration. The platform can also record which Agent used a connection and allow a user or administrator to revoke it.
+
+Agent Plugins has standardized component packaging and discovery. Leaving authentication to clients is an intentional v1.0.0 boundary. Multi-user web Agent platforms still have to provide connection UX, credential isolation, short-lived injection, audit records, and revocation. Until plugins can declare those connection requirements portably, cross-client loading will not provide a consistent authentication experience.
+
+## References
+
+- [Agent Plugins](https://agent-plugins.org/)
+- [Agent Plugins v1.0.0 Working Draft](https://agent-plugins.org/specification)
+- [Agent Plugins governance](https://github.com/agentplugins/agent-plugins-spec/blob/main/GOVERNANCE.md)
+- [Agent Plugins maintainers](https://github.com/agentplugins/agent-plugins-spec/blob/main/MAINTAINERS.md)
+- [MCP Authorization](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)
+- [Agent Plugins future considerations](https://github.com/agentplugins/agent-plugins-spec/blob/main/FUTURE_CONSIDERATIONS.md)

blog/2026-08-06-managed-agents-cloud-harness-vs-sandbox-harness.mdx

@@ -0,0 +1,77 @@
+---
+slug: managed-agents-cloud-harness-vs-sandbox-harness
+title: Managed Agent Harness Architectures and Trade-offs
+description: A comparison of control-plane and sandbox-local harnesses for one-off automation, long-running agents, state recovery, multi-sandbox orchestration, and governance.
+image: /img/blog/managed-agents-harness-architecture-cover-en.webp
+authors: [xfgong]
+tags: [Managed Agents, Agent Harness, Sandbox, Agent Platform]
+---
+
+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.
+
+<!-- truncate -->
+
+## Harness placement determines the agent lifecycle
+
+The harness stores context, sends model requests, handles tool calls, and decides the next action. It also manages retries, approvals, budgets, and subagent scheduling. To locate the harness, look at which component owns the context and initiates the next model turn. A sandbox supplies execution resources such as files, processes, browsers, and network access.
+
+![Two harness runtime architectures for Managed Agents](/img/blog/managed-agents-architecture/harness-placement-comparison-en.svg)
+
+This article treats a sandbox as an isolated execution resource with command, file, process, and state lifecycle APIs. It does not repeat the comparison between containers, Kubernetes, and MicroVMs. For scheduling, pause and resume, and snapshot semantics across sandbox implementations, see [OpenSandbox vs. CubeSandbox: Choosing Between Kubernetes Resources and a MicroVM Runtime Stack](./opensandbox-vs-cubesandbox-agent-platform-selection).
+
+## Sandbox-local harnesses fit one-off tasks
+
+A sandbox-local harness has practical advantages. Shells, files, PTYs, and browsers are local, so tool calls do not need a remote execution protocol. Code indexing, large-file processing, and long-running terminal processes avoid repeated result transfers. The platform can also pin the harness, dependencies, and workspace in one image, making a run reproducible and easier to deliver into a customer VPC.
+
+This structure works best when one task maps to one runtime. Fixing an issue, generating a report, or processing a dataset has a clear beginning and end. Once the task finishes, the platform destroys the sandbox. Recovery and version migration rarely dominate the design, and multi-tenant isolation is straightforward when each task or user receives a separate container.
+
+Long-running agents change those assumptions. An agent may wait for approval, receive a webhook hours later, and return to the same project the following week. When the harness lives inside the sandbox, the platform must either keep that environment or suspend its processes, context, and workspace together. A filesystem snapshot captures only part of the state. Pending tool calls, PTYs, local services, and the model loop still need recovery semantics.
+
+Harness versions also accumulate across existing sandboxes. After a permission bug is fixed, the platform must migrate or terminate old instances. Model keys and external-tool credentials enter the same failure boundary as untrusted code and the harness process. Short-lived tokens and credential brokers reduce the risk, but add more infrastructure.
+
+## Long-running agents need independent state
+
+A control-plane harness can preserve an agent without preserving a sandbox. Conversation history, memory, budgets, approval state, and run events remain available while execution environments are created only when needed. An agent consumes no sandbox while it waits for a message or timer. Its next run can reconnect to the previous workspace or start a new environment from a snapshot.
+
+Some steps require no execution environment at all. The model can read prepared context, call a remote MCP server, or wait for confirmation. File operations can target a virtual filesystem until a shell, browser, or local process becomes necessary. Keeping the agent alive no longer means keeping one machine alive.
+
+Recovery becomes easier to separate. If a sandbox fails, the harness retains completed steps and the latest observation, then continues on another machine. If a harness worker fails, an event log, checkpoint, and lease can restore the run on another worker. Agent state and execution resources have separate failure boundaries.
+
+The cost is a remote execution protocol. Shells, files, PTYs, browsers, and streaming logs all need API representations. After a network interruption, the control plane may not know whether a command completed, so the protocol needs idempotency keys, leases, heartbeats, reconnection, and explicit command states. Large files and logs require object storage or reference-based transfer. The control plane also becomes a shared multi-tenant failure domain and must limit each agent's concurrency, context memory, model requests, and event writes.
+
+## Multi-sandbox orchestration belongs in the control plane
+
+Long-running agents often need more than one execution environment. A coding agent can test several fixes in separate sandboxes and compare the results. Test runs can cover different operating systems, dependency versions, or browsers in parallel. Authenticated browser sessions, code workspaces, and GPU jobs may also require different network and credential policies.
+
+A control-plane harness can manage those resource leases directly. It records the state and budget of each branch, then handles cancellation, partial failure, and result merging. A sandbox-local harness can request additional sandboxes, but it must then hold scheduling privileges and manage resources from a temporary execution environment. Over time, the platform usually adds an external task table, scheduler, approval service, and recovery state.
+
+A platform can also extend a sandbox-local harness with external checkpoints, full memory snapshots, credential brokers, and a session scheduler so that one session can resume across sandboxes. Perplexity SPACE demonstrates a design in which a session is separated from an individual sandbox and can be paused or branched. At that point, long-term state and resource orchestration have moved outside the sandbox, and the system has acquired the main characteristics of a control-plane harness.
+
+![Sandbox lifecycle and parallel orchestration under a cloud harness](/img/blog/managed-agents-architecture/control-plane-multi-sandbox-en.svg)
+
+## Governance belongs in the control plane
+
+A multi-user agent platform must manage identities, permissions, approvals, budgets, and audit records consistently. When the harness runs in the control plane, those policies can be evaluated before model requests and tool execution. Model keys and long-lived credentials can remain in the managed service while a sandbox receives only short-lived permission for a specific operation.
+
+Sandboxes still need network-egress and filesystem restrictions. A control-plane harness also consumes untrusted repository content, webpages, and tool results. Prompt injection can still induce it to call privileged tools. Harness placement does not solve security by itself; it gives policy enforcement a stable place to run.
+
+For one-off automation, putting a mature harness inside a sandbox remains the shortest path. For a long-running Managed Agent, users, sessions, and permissions persist while the sandbox is only an occasional compute resource. That model benefits from a control plane independent of the execution environment.
+
+## CubePlex architecture direction
+
+CubePlex uses a control-plane harness with independent sandboxes. CubePi manages the agent loop, context, MCP routing, approvals, and traces. Sandboxes provide isolated shells, files, browsers, and artifact execution environments. High-frequency local operations can run in a restricted sandbox worker, while the control plane retains the agent trajectory, long-lived credentials, and approval state.
+
+CubePlex already uses a centralized CubePi run path with independent sandboxes. Managed Agent definitions and one-to-many sandbox orchestration remain future architecture work and should not be presented as delivered product capabilities. The current priority is to fix each Managed Agent's version, runtime identity, and audit context, then treat sandboxes as execution resources that can be leased, replaced, and scheduled in parallel.
+
+One task can remain bound to one sandbox. A long-running Managed Agent should persist and lease sandboxes only when execution is required. That is why CubePlex chose a control-plane harness.
+
+## References
+
+- [OpenHands Runtime Architecture](https://docs.openhands.dev/openhands/usage/architecture/runtime)
+- [Claude Managed Agents](https://platform.claude.com/docs/en/managed-agents/overview)
+- [Claude Code Action](https://github.com/anthropics/claude-code-action)
+- [VibeKit](https://github.com/superagent-ai/vibekit)
+- [LiteLLM Agent Platform](https://github.com/BerriAI/litellm-agent-platform)
+- [Buzz](https://github.com/block/buzz)
+- [Manus Sandbox](https://manus.im/blog/manus-sandbox)
+- [Perplexity SPACE](https://hub-prod.perplexity.ai/hub/blog/secure-sandboxes-for-agents)

docusaurus.config.ts

@@ -7,8 +7,8 @@ const classicOptions: ClassicOptions = {
   blog: {
     routeBasePath: '/',
     showReadingTime: true,
-    blogSidebarCount: 3,
-    blogSidebarTitle: 'Recent posts',
+    blogSidebarCount: 'ALL',
+    blogSidebarTitle: 'All articles',
     editUrl: 'https://github.com/cubeplexai/blog/edit/main/',
     editLocalizedFiles: true,
     feedOptions: {

i18n/zh-Hans/code.json

@@ -1,42 +1,33 @@
 {
-  "blog.recentPosts.ariaLabel": {
-    "message": "最新文章"
+  "blog.allPosts.ariaLabel": {
+    "message": "全部文章"
   },
-  "blog.recentPosts.title": {
-    "message": "最新文章"
+  "blog.allPosts.title": {
+    "message": "全部文章"
+  },
+  "blog.allPosts.showAll": {
+    "message": "查看全部 {count} 篇文章"
+  },
+  "blog.allPosts.showLess": {
+    "message": "收起"
   },
   "blog.productCallout.eyebrow": {
-    "message": "继续构建"
+    "message": "开源项目"
   },
   "blog.productCallout.title": {
-    "message": "从智能体想法，到可靠的实际工作。"
+    "message": "把 Agent 接进团队的日常工作"
   },
   "blog.productCallout.cubeplexDescription": {
-    "message": "将对话、技能、共享记忆、MCP 集成与自动化纳入团队可治理的工作空间。"
+    "message": "面向团队的自托管 AI Agent 工作空间，用来处理文档、数据和跨系统任务，并统一管理权限与执行记录。"
   },
   "blog.productCallout.cubepiDescription": {
-    "message": "使用持久化、工具、流式输出和追踪来构建异步 Python 智能体，同时始终掌握运行时。"
+    "message": "高性能、可追踪、生产级持久化的 Python 原生异步 Agent 框架。"
   },
   "blog.productCallout.cubeplexCta": {
-    "message": "在 GitHub 查看 CubePlex"
+    "message": "查看 CubePlex 源码"
   },
   "blog.productCallout.cubepiCta": {
-    "message": "在 GitHub 查看 CubePi"
-  },
-  "blog.intro.kicker": {
-    "message": "CubePlex 博客"
-  },
-  "blog.intro.heading": {
-    "message": "受治理的智能体工作。"
-  },
-  "blog.intro.description": {
-    "message": "面向构建可治理、自托管智能体工作流团队的产品与工程笔记。"
-  },
-  "blog.intro.documentationCta": {
-    "message": "阅读文档"
-  },
-  "blog.intro.imageAlt": {
-    "message": "带有笔记本电脑和流程图的简洁技术工作空间"
+    "message": "查看 CubePi 源码"
   },
   "theme.ErrorPageContent.title": {
     "message": "页面已崩溃。",