Agent Runtime

The core flow of a Vibe Coding platform is: the user says something → the Agent loops through LLM and tool calls → a deployable application is produced. To make this flow work reliably, platforms face the following key challenges at the Agent runtime layer:

• Security boundaries: The Agent needs to operate cloud resources (databases, deployments, etc.), but LLM output is unpredictable — secrets must never be exposed to the LLM or its generated code
• Agent orchestration & session continuity: The Agent Loop must orchestrate prompts, route tool calls, and manage session state. User conversations may span multiple turns and days — both context and sandbox workspaces need to be persisted
• Code execution environment & elasticity: LLM-generated code (npm install, build, running user logic) needs a secure, isolated environment — it cannot run directly on the production server. Sandbox instances should be created and destroyed on demand, with no resource consumption when idle
• Model flexibility: Different tasks call for different models (strong reasoning models for code generation, lightweight models for simple Q&A). The platform needs to switch flexibly

CloudBase provides corresponding solutions for each of these challenges:

Challenge	CloudBase Solution
Security boundaries	Controlled trust boundaries — Agent Loop as the sole credential holder; LLM and Sandbox are unaware of secrets
Agent orchestration & session continuity	Agent Loop — deployed in Cloud Functions, drives loop control, session management (CloudBase Database persistence), credential management
Code execution environment & elasticity	Sandbox — isolated container/microVM, created/reclaimed on demand, workspace persisted to COS/CFS across conversations
Model flexibility	MaaS Model Service — unified multi-model access, dynamically switchable by task type

The following sections start with the Core Architecture for the big picture, then walk through each component in detail.

---

Core Architecture

---

Controlled Trust Boundaries

The core design principle of the runtime architecture is controlled trust boundaries — constraining unpredictable components within well-defined security boundaries, with every cross-boundary operation mediated by the Agent Loop as the trusted intermediary.

The system is divided into three trust levels:

Trust Layer	Component	Trust Level	Credentials	Description
Trusted	Agent Loop	✅ Trusted	Holds all credentials	Deterministic code written by the platform — controllable and auditable
Untrusted — Reasoning	LLM	❌ Untrusted	None	Output is unpredictable; may be affected by prompt injection or hallucinations
Untrusted — Execution	Sandbox	❌ Untrusted	Env-level secrets only (for MCP)	Executes arbitrary LLM-generated code in an isolated sandbox

Why must the LLM and Sandbox remain outside the trust boundary?

• LLM: Model output is unpredictable. If the LLM were aware of secrets, malicious prompt injection could trick the model into embedding secret-exfiltration logic in generated code
• Sandbox: The code it executes is generated by the LLM and its content is uncontrollable. If the Sandbox held platform-level secrets, malicious code could exfiltrate keys via curl, call management APIs directly to delete data, or attack other users' environments

Therefore, the Agent Loop serves as the sole trusted intermediary for all cross-boundary operations: the LLM can only "request" operations, the Sandbox can only "execute" within a constrained scope, and real decision-making authority and credentials always remain under the Agent Loop's control.

---

Request Lifecycle

A complete Vibe Coding request goes through the following stages from user input to application deployment:

---

Agent Loop

The Agent Loop is business code deployed as a CloudBase Cloud Function, responsible for driving the entire request lifecycle.

Loop Control

The core of the Agent Loop is a "call LLM → execute tools → feed back results" cycle:

1. Assemble user input + session context + tool definitions into a prompt and send it to the LLM
2. Parse the LLM's returned Tool Calls and route them to the corresponding tools (Sandbox SDK or MCP Client)
3. Append tool execution results back into the prompt and continue the next iteration
4. When the LLM returns final text (not a tool call), end the loop and respond to the user

Session Management

Session state is persisted to CloudBase Database, including:

• Conversation history: the complete message list (user / assistant / tool)
• Context metadata: current Sandbox instance ID, workspace snapshot ID, user environment ID, etc.
• State machine: the current phase of the request (coding / building / deploying / completed)

Credential Management

The Agent Loop holds the following credentials via Cloud Function environment variables. No credential is ever passed to the LLM or exposed in the Sandbox workspace:

Credential	Purpose
LLM API Key	Call the LLM inference API
User CloudBase env secrets (SecretId / SecretKey)	Issue env-level temporary credentials, injected into the Sandbox for MCP use
Business secrets	Held as needed, e.g. GitHub Token (pull code repos), NPM Token (access private packages), third-party API Keys, etc.

---

Sandbox

The Sandbox is the Agent's programming tool layer, providing a fully isolated OS environment built on CloudBase Sandbox.

Capability Overview

Capability	Description
Filesystem	Read-write workspace directory with support for read / write / list / remove / stat / mkdir
Shell execution	Run arbitrary shell commands and return stdout / stderr / exitCode
CloudBase MCP	Run the CloudBase MCP Server inside the Sandbox and expose cloud resource operations over stdio
Lifecycle management	Support create / pause / resume / destroy, as well as snapshots
Workspace persistence	Persist the workspace via COS (checkpoint) or CFS (mount), ensuring it survives across conversations and instances
Isolation	Each user's Sandbox is isolated from every other; no platform-level management credentials
Low latency	Tool invocation latency is typically < 500ms
Resource quota	Disk ≥ 512MB, configurable command timeout (≥ 5 minutes)

Workspace Persistence

The Sandbox instance itself is ephemeral, but the workspace must survive across conversations. Recommended options:

Option	I/O Performance	Consistency	Cost
Mount CFS	Close to local disk	Strong consistency	Higher
Checkpoint to COS	Equivalent to local after restore	Eventual consistency	Lower

The core workload of Vibe Coding is high-frequency small-file read/write (npm install can generate tens of thousands of small files), so it is highly sensitive to I/O performance.

Integration Example

Note: the Sandbox SDK is currently in limited preview. Contact the product team for access.

// 1. Issue user env-level temporary credentials
const credentials = await generateEnvCredentials(userEnvId);

// 2. Start the Sandbox with user-level secrets injected
const sandbox = new AgentSandbox({
  envId: userEnvId,
  secretId: agentConfig.secretId,   // Platform credentials, used only for Sandbox SDK RPC auth
  secretKey: agentConfig.secretKey,
  envVars: {
    // User CloudBase env secrets (for MCP Server)
    CLOUDBASE_ENV_ID: userEnvId,
    TENCENTCLOUD_SECRETID: credentials.secretId,
    TENCENTCLOUD_SECRETKEY: credentials.secretKey,
    // User business secrets (injected as needed)
    GITHUB_TOKEN: user.githubToken,
    NPM_TOKEN: user.npmToken,
  }
});

// 3. Filesystem operations (wrapped as Agent Tools for LLM)
await sandbox.files.write('/app/index.js', code);
const content = await sandbox.files.read('/app/index.js');
await sandbox.files.list('/app');

// 4. Execute shell commands
const result = await sandbox.commands.run('npm install && npm run build');
// result: { stdout, stderr, exitCode }

// 5. Workspace persistence
await sandbox.snapshot(sessionId);   // persist to COS/CFS
await sandbox.restore(sessionId);    // restore from COS/CFS

CloudBase MCP Integration

The CloudBase MCP service runs inside the Sandbox, and the Agent Loop communicates with it through an MCP Client (stdio protocol). Using the sandbox instance created above:

// 1. Start the CloudBase MCP Server inside the Sandbox
await sandbox.commands.run('npx @cloudbase/cloudbase-mcp@latest');

// 2. Call cloud resource operations via MCP Client
const mcpClient = sandbox.connectMCP({ transport: 'stdio' });
await mcpClient.call('cloudbase.db.createCollection', { name: 'todos' });
await mcpClient.call('cloudbase.function.deploy', { name: 'addTodo', code: '...' });

Note: the user's environment-level credentials were already injected when the Sandbox started (see envVars above). The MCP Server uses them to call management APIs, and can only operate on that specific user's CloudBase environment. Its permission scope is intentionally limited.

---

MaaS Model Service

CloudBase provides a unified access layer for large language models, allowing platform teams to choose and switch models flexibly.

• Multi-model access: Unified access to mainstream large models such as DeepSeek, Hunyuan, GLM, MiniMax, and Kimi
• Dynamic switching: Platform teams can choose models dynamically based on task type (for example, strong reasoning models for code generation and lightweight models for simple conversations)
• Unified billing: Model usage is billed in a unified way, making costs easier to control
• Flexible deployment: Supports both public-cloud model APIs (low cost, no infrastructure maintenance) and private deployment (data stays inside the private network, suitable for high-security scenarios)