AlchemiStudioAlchemiStudio
Product 04 // Infrastructure

COMPUTE

>>> EXECUTING|

Every agent run gets a fresh, isolated sandbox. Provisioned in under a second, destroyed when the run ends. Kernel-level memory isolation. Zero shared state between runs.

Book a Demo

<1s

SANDBOX STARTUP

ZERO

BLAST RADIUS

ISO 27001SOC 2 Type IICVE-SAFEKERNEL-LEVEL

// SIX_PRIMITIVES

SIX ISOLATION PRIMITIVES.

Each primitive is enforced at the hypervisor level. Together they make the failure modes of shared AI infrastructure architecturally impossible.

◼ COMPUTE_OS
10:24 AM
VIZ_VIEWER :: PRIM_01
_
×
Sandbox Instances - alchemi.compute
-
o
x
FileViewHelp
Sandbox ID / AgentStartupStatus

sb_8a2f

pipeline-bot / 512 MB

0.83s
READY

sb_3c9e

churn-analyzer / 256 MB

0.61s
READY

sb_f14b

lead-scorer / 512 MB

0.79s
RUNNING

sb_9d2a

report-bot / 256 MB

0.92s
READY
Avg. startup: 0.79s+1 provisioned this second
PRIM_01_SPEC.txt — Notepad
_
×

Just-in-Time Provisioning

> A fresh, fully isolated sandbox is provisioned in under one second for every agent run — on demand, with no pre-warming and no shared state from previous runs. Each sandbox has its own filesystem, network scope, and process tree. No contamination risk, no cold-start penalty.

// CAPABILITIES
[OK]Sub-second provisioning for every run — no warm pools required
[OK]Each sandbox has its own filesystem and process tree
[OK]Zero shared state between any two runs
[OK]Scales to thousands of concurrent sandboxes instantly
<1sHypervisorEphemeral
Get early access →
■ START
PRIM_01JUST-IN-TIME PROVISIONING
10:24 AM
ALCHEMI  COMPUTE
PWR
◼ COMPUTE_OS
02:17 PM
VIZ_VIEWER :: PRIM_02
_
×
Memory Isolation - alchemi.compute
-
o
x
ENFORCEDAll runs isolated at kernel level
run_8a2f / pipeline-botISOLATED
context.csvcrm_cacheno shared memory
run_3c9e / churn-botISOLATED
context.jsonembed_cacheno shared memory
run_f14b / finance-botISOLATED
forecast.xlsxno shared memory
Zero cross-run memory leakage guaranteed
PRIM_02_SPEC.txt — Notepad
_
×

Complete Memory Isolation

> Each run's memory is fully isolated at the kernel level. No data leakage between runs, agents, teams, or users — not as a policy, but as a hardware-enforced architectural guarantee. Agent A cannot read Agent B's data even when both run simultaneously on the same physical host.

// CAPABILITIES
[OK]Kernel-level memory isolation — not just process separation
[OK]Architecturally impossible for one run to access another's memory
[OK]Verified at the hypervisor level, not just the OS
[OK]Concurrent runs on the same host remain fully isolated
Kernel-levelCVE-safeHypervisor
Request a Compute demo →
■ START
PRIM_02COMPLETE MEMORY ISOLATION
02:17 PM
ALCHEMI  COMPUTE
PWR
◼ COMPUTE_OS
09:45 AM
VIZ_VIEWER :: PRIM_03
_
×
Runtime Secret Injection - run_8a2f
-
o
x
Secret NameStatus
OPENAI_API_KEYREVOKED
POSTGRES_DSNREVOKED
Secrets auto-revoked at run end / never stored on disk
PRIM_03_SPEC.txt — Notepad
_
×

Runtime Secret Injection

> API keys, database passwords, and service credentials are injected into the sandbox at runtime — in memory only, never written to disk, never stored in agent code, never in logs. When the sandbox is destroyed at run completion, the credentials are gone with it.

// CAPABILITIES
[OK]Secrets injected at run start, in memory only
[OK]Never written to disk, config files, or environment variables
[OK]Auto-revoked the moment the sandbox is destroyed
[OK]Zero persistent credential surface across the entire platform
Zero-trustRuntimeVault-compat
Talk to our security team →
■ START
PRIM_03RUNTIME SECRET INJECTION
09:45 AM
ALCHEMI  COMPUTE
PWR
◼ COMPUTE_OS
11:30 AM
VIZ_VIEWER :: PRIM_04
_
×
Resource Monitor - run_f14b
-
o
x
CAPS ENFORCEDHypervisor-level enforcement
CPU
72%/ 85%
Memory
61%/ 80%
Time
8s/ 15s
Hard stop at cap / run will be terminated
PRIM_04_SPEC.txt — Notepad
_
×

Hard Timeouts & Resource Caps

> Every sandbox has hard CPU, memory, and wall-clock time limits enforced at the hypervisor level — not soft guidelines in application code, but kernel-enforced boundaries. An agent stuck in an infinite loop or calling a slow external API indefinitely is hard-stopped and torn down immediately.

// CAPABILITIES
[OK]Wall-clock timeout enforced at the hypervisor — not app-level
[OK]CPU and memory caps prevent resource starvation of other runs
[OK]Hard-stop on timeout: teardown begins immediately
[OK]Configurable per-agent or per-team via Cockpit policies
cgroupsCPU / MemHypervisor
Get early access →
■ START
PRIM_04HARD TIMEOUTS & RESOURCE CAPS
11:30 AM
ALCHEMI  COMPUTE
PWR
◼ COMPUTE_OS
03:52 PM
VIZ_VIEWER :: PRIM_05
_
×
Completed Runs - teardown log
-
o
x
Run / AgentDurationSandbox

run_8a2f

pipeline-bot / teardown in <50ms

1.42s
DESTROYED

run_3c9e

churn-analyzer / teardown in <50ms

0.89s
DESTROYED

run_9d2a

lead-scorer / teardown in <50ms

2.10s
DESTROYED

run_4b1c

report-bot / teardown in <50ms

3.31s
DESTROYED
No persistence / zero idle sandboxes0 LIVE IDLE
PRIM_05_SPEC.txt — Notepad
_
×

Auto-Teardown on Completion

> The moment a run completes — whether successfully, failed, or timed out — teardown begins immediately. The process tree is destroyed. Memory pages are zeroed. Credentials are revoked. File handles are closed. The sandbox ceases to exist in under 50ms. Zero idle infrastructure between runs.

// CAPABILITIES
[OK]Sandbox destroyed in <50ms on run completion
[OK]Memory zeroed, credentials revoked, process tree destroyed
[OK]Triggered on success, failure, or timeout — no exceptions
[OK]Zero idle infrastructure means zero idle cost between runs
<50msZero-idleEphemeral
Request a Compute demo →
■ START
PRIM_05AUTO-TEARDOWN ON COMPLETION
03:52 PM
ALCHEMI  COMPUTE
PWR
◼ COMPUTE_OS
08:00 AM
VIZ_VIEWER :: PRIM_06
_
×
Code Execution Sandbox - run_8a2f
-
o
x
step 2 of 5 / python3SANDBOXED0 HOST ACCESS

C:\sandbox> python3 analysis.py

Loading data... OK

PRIM_06_SPEC.txt — Notepad
_
×

Code Execution Safety

> When agents generate and execute code, that code runs inside the sandbox — not on shared infrastructure. No network access beyond explicitly approved endpoints. No filesystem writes outside the sandbox. No access to the host or other sandboxes. Arbitrary code execution is fully contained by design.

// CAPABILITIES
[OK]Agent-generated code runs inside the sandbox, not shared infra
[OK]No host network access — only explicitly approved endpoints
[OK]No filesystem writes outside the sandbox boundary
[OK]Arbitrary code execution fully contained at the hypervisor level
SandboxAir-gapOWASP Top 10
Talk to our security team →
■ START
PRIM_06CODE EXECUTION SAFETY
08:00 AM
ALCHEMI  COMPUTE
PWR

// LIFECYCLE TOUR

EVERY RUN. SAME FOUR PHASES.

The Compute lifecycle is deterministic. Every agent run — whether triggered by Copilot, Console, or Cockpit — follows the same four-phase lifecycle.

STEP_01

PROVISIONING

A fresh, isolated sandbox is provisioned in under one second. Memory is allocated. Network scope is defined. Credentials are injected at runtime. No shared state from previous runs, no pre-warmed pools, no contamination risk.

STEP_02

EXECUTING

The agent runs inside the sandbox. It can call tools, generate code, access the web, and read approved data — all within the exact scope set by Cockpit policies. Every action is traced. Resource caps are enforced at the hypervisor level.

STEP_03

TEARDOWN

When the run completes (successfully, failed, or timed out), teardown begins immediately. The process tree is destroyed. Memory pages are zeroed. Credentials are revoked. No lingering processes, no file leaks, no persistent state.

STEP_04

COMPLETE

The trace is committed to the audit log. The output is returned to the caller — Copilot shows it in the Canvas, Console surfaces it in the trace view, Cockpit logs it for compliance. Persistence is exactly what you asked for, nothing more.

// USE_CASES

WHY ISOLATION MATTERS.

Each primitive addresses a distinct failure mode. These are the risks Compute makes architecturally impossible.

JIT ProvisioningDevOps · Cloud Platform

100 concurrent runs, zero cold-start delay

A batch trigger fires 100 agent runs simultaneously. On pre-warmed shared infra, the first runs monopolize warm slots. With Compute's JIT model, all 100 provision fresh sandboxes in under a second — no queuing, no cold-start tax.

  • Sub-second provisioning regardless of concurrency
  • No shared pool — no queue, no cold-start
  • Scales to thousands of concurrent runs
Memory IsolationSecurity Team · Financial Services

Proving Agent A cannot read Agent B's data

A regulator asks for proof that concurrent agent runs processing different customers' data cannot share memory. Compute's kernel-level isolation makes this architecturally impossible — provable by design, not just policy.

  • Kernel-level isolation — not just process separation
  • Architecturally impossible, not just policy-controlled
  • Audit evidence for regulatory compliance
Secret InjectionCISO · Enterprise SaaS

API keys injected, never stored

Traditional approaches store API keys in environment variables or config files — a persistent attack surface. Compute injects credentials at runtime, in memory only. When the sandbox is destroyed, the credentials are gone with it.

  • Runtime injection — never written to disk
  • Zero persistent credential exposure
  • Auto-revoked on sandbox teardown
Resource CapsPlatform Engineering · Healthcare

A rogue agent can never exhaust shared infra

An agent stuck in an infinite loop or calling a slow external API indefinitely would starve other runs on shared infra. Compute's hypervisor-level timeouts and resource caps hard-stop any run that exceeds its bounds.

  • Hypervisor-enforced — not app-level limits
  • Hard wall-clock timeout per run
  • Other runs unaffected by a single rogue agent
Auto-TeardownFinance / Procurement · SaaS

Zero idle infrastructure cost between runs

On always-on infra, idle compute between runs costs money 24/7. Compute destroys sandboxes in <50ms after run completion. Zero idle time, zero idle cost — infrastructure spend proportional to actual agent usage.

  • Sandbox destroyed in <50ms on completion
  • Zero idle infra between runs
  • Cost exactly proportional to actual usage
Code SafetySecurity Engineering · Enterprise SaaS

Agent-generated code can't touch production

An agent generates and executes code to process a data file. On shared infra, that code could write to the filesystem or open network connections. Inside Compute's sandbox, it can do none of those things.

  • No host network access — only approved endpoints
  • No filesystem writes outside sandbox boundary
  • Arbitrary code execution fully contained

// FULL SPEC

EVERYTHING COMPUTE GUARANTEES.

Just-in-Time Provisioning

Sandboxes provisioned in under one second, on demand. No pre-warming, no shared pool. Every run gets a fresh environment the moment it starts.

Complete Memory Isolation

Kernel-level isolation. No cross-contamination between runs, users, or agents. Architecturally impossible to read memory from another run.

Runtime Secret Injection

API keys and credentials injected at runtime. Never written to disk. Revoked automatically when the sandbox is destroyed.

Hard Timeouts & Resource Caps

Every run has a wall-clock timeout. Hypervisor-enforced CPU and memory caps. Runaway agents cannot consume unbounded resources.

Auto-Teardown on Completion

Sandbox destroyed immediately on run completion: success, failure, or timeout. No lingering processes, no file leaks, zero persistent state.

Code Execution Safety

Agents that generate and run code do so inside the sandbox, not on shared infra. Arbitrary code execution is fully contained. Production is never at risk.