Skip to content
Category comparison

Execution sandboxes vs an agent backend

Execution sandboxes are useful when an agent needs isolated compute, files, tests, browsers, or desktop sessions. General Augment is the agent backend for the product: it can govern the app user, tools, approvals, traces, and connector actions that point to customer-owned capacity when needed.

Connect private capacity Learn the category

Use execution sandboxes when

  • The agent needs an isolated environment for code, files, browsers, or desktop work.
  • The compute host is the product decision.
  • You only need a place for tasks to run.

Use General Augment when

  • The product needs one governed agent backend across users and surfaces.
  • Private capacity should be exposed as narrow approved actions, not raw access.
  • The app needs memory, identity, usage, traces, and approvals around those actions.
Decision table

Compare the layer, not just the feature list.

Decision area
execution sandboxes
General Augment
Compute

Sandboxes provide isolated files, commands, browsers, tests, and runtime environments.

General Augment governs when a product agent can use that capacity for the right app user.

Security boundary

A sandbox may still expose broad shell, filesystem, or network capabilities if the product wires it directly.

Expose narrow approved actions with redaction, audit, usage, policy, and trace evidence.

Product context

The sandbox usually does not own app identity, billing, permissions, channels, or memory.

Those app-agent concerns stay centralized in the General Augment project.

Architecture fit

Where the categories fit together.

A sandbox can be a connector substrate. General Augment governs when and how the product agent uses that capacity for the right app user.

Governed connector shape
Customer-owned host
  GET /health
  POST /v1/actions/{capability}

General Augment exposes the capability as a governed tool
with policy, approval, audit, redaction, usage, and traces.
Migration path

Start where you are. Add the agent backend when the product needs it.

  1. 01
    Use a sandbox provider for code, files, browser, or test execution.
  2. 02
    Define a small set of safe capabilities that the product agent can request.
  3. 03
    Connect those capabilities to General Augment as governed tools or connector actions.
  4. 04
    Require approval for deploys, publishes, external sends, or expensive tasks.
Specific examples

Coding sandbox

A developer product exposes build and test actions, but General Augment controls task policy, approvals, and trace evidence.

Private VM

An operations team keeps private files and internal services on its own host while exposing only bounded action endpoints.

Browser automation

The assistant can request a narrow browser task without receiving raw credentials, unrestricted network access, or local paths.

When not to use General Augment

Use the smaller tool when the smaller tool is enough.

Use only a sandbox when the product decision is simply where compute should run.
Use only a sandbox when there is no app-user memory, approval, or channel workflow around the work.
Use only a sandbox when unrestricted shell-like execution is intentionally the whole product.
FAQ

Does General Augment include a sandbox?

General Augment can connect to sandboxed or customer-owned capacity, but its main role is the policy, memory, identity, approval, usage, and trace layer around product-agent work.

Can customers bring their own execution host?

Yes. Private hosts, VMs, local machines, coding sandboxes, and provider accounts can expose narrow governed actions without moving broad execution into the hosted platform.

When is a sandbox enough?

A sandbox is enough when the only problem is isolated compute. General Augment matters when that compute needs product identity, permissions, memory, approvals, and audit.