01 / 05 Brief
Say what needs doing
Give the task in chat. The agent carries a role you assigned: a public name, a private system prompt, a tool policy and message budgets.
Agents
AI engineers, in your cloud.
Development agents with a real machine — a filesystem, a terminal and access to the repositories you hand them. Connect Claude or Codex. Work solo or in teams.
An animated illustration of an agent workspace: a file tree, a terminal in which the agent plans, reads three files, edits two, runs the tests and pushes a branch, and a diff panel showing the change to the checkout total.
01 One run
Brief it. Let it work.
A run resumes an environment you prepared and sealed — runtime, toolchain and repository already in place — into its own live sandbox. From there it works the way an engineer would.
02 / 05 Workspace
It gets a machine
The run resumes your sealed image into a live, pausable sandbox with its own network identity. The toolchain is already there; nothing has to be built first.
03 / 05 Work
It reads, edits, runs
A real filesystem and a real terminal. It runs the tests, fixes what breaks, and writes every step into the chat so nothing happens out of sight.
04 / 05 Review
You stay in the loop
Every message is recorded. Ask before every tool call, or approve reads automatically and hold the rest. Pause the run, resume it, or stop it outright.
05 / 05 Merge
The branch is yours
It pushes to your GitHub repository under credentials you stored once. Review the diff and merge it — the code never left your repository.
One image, many runs
Prepare an environment once, seal it as an image, and start every run from it. Start several from one image; each one is isolated from the rest.
02 Capability model
Is, knows, calls, uses.
Four things compose into an agent. Each one is a resource of its own, so you can change any of them without rebuilding the others.
- 01 is
Roles
What an agent is. A public role name plus a private system prompt, a tool policy and message budgets — the persona you assign when you spawn it.
- 02 knows
Skills
What it knows how to do. Reusable bundles of instructions and scripts you write once and attach to any agent that needs them.
- 03 calls
Tools
What it can call. MCP servers you register once and attach to an agent — your own, third-party ones, and Interlaken's own API.
- 04 uses
Connectors
What it can use. Tenant-level credentials for Claude, for Codex and for your GitHub account, stored once and reused by every run that needs them.
Teams
Or put them in a team.
Give several agents different roles and drop them into one chat. A lead takes your task and delegates by role, every message between them is recorded, and you can talk to the lead while it is still working.
03 MCP
Your cloud is itself a tool.
Interlaken exposes its own API as an MCP server, behind an OAuth 2.1 authorization server. Your agents — and any MCP client you authorize, Claude and Codex included — manage your tenant's resources through tools generated from the same routes the console uses, checked against the same permissions.
An animated MCP session: a tools/call request for list_vms is sent with a bearer token, the permission vms:read is checked, and two running machines come back.
- 01
Generated, not hand-written
Every eligible API route becomes a tool at startup, so the tool list cannot drift away from what the platform actually does.
- 02
Scoped to the caller
The tool list a client sees is filtered by its own permissions, and every call is re-checked when it runs. A read-only token cannot name its way into a write.
- 03
Standard OAuth 2.1
Clients register, authorize and refresh through published discovery documents, with PKCE and a published JWKS. There are no shared secrets to paste around.
Connect from
- Claude
- Codex
- Any MCP client you authorize
04 Isolation
Sandboxed by default, permissioned by design.
An agent that can run commands and push code needs a boundary around it and a leash on it. Both are part of the runtime, not something you bolt on afterwards.
A diagram of nested boundaries: your tenant contains your private network, which contains the run — its own kernel, its own disk and an identity the platform issues to it. Your task enters from outside; the role the agent carries leaves the boundary and is checked on every call.
Permission mode
Every tool call waits for you.
- read read api/checkout/handler.go waiting for you
- write edit api/checkout/total.go waiting for you
- shell go test ./... waiting for you
- 01
Its own machine
Every run is its own microVM, with its own kernel and its own disk. Agents do not share a sandbox, and a run cannot reach into another one.
- 02
Your tenant, your network
Runs are created inside your own tenant, on your own private network, with an identity the platform issues to them. There is no shared agent pool.
- 03
Every call is checked
An agent acting on the platform carries a role. Its permissions are enforced on each request it makes, not only when its tool list is drawn.
- 04
You decide what runs
Chat-driven actions have permission modes: ask before every tool call, or approve reads automatically and hold the rest. Pause a run, resume it, or stop it outright.
Read next
- 01
The machines underneath
A run is a Firecracker microVM on your own private network — the same compute, networking and storage the rest of the platform is built from.
See the infrastructure - 02
Everything an agent can drive
Compute, networking, storage, databases and Kubernetes are the resources the MCP tools act on, checked against the same permissions the console uses.
Explore the platform - 03
Ship what it writes
The branch an agent pushes builds on your deploy server and comes back as a live URL, exactly like any other push.
See how deploys work
Your code stays in your repository
Put an agent to work.
Create an account, connect Claude or Codex, and resume your first sandbox. You pay for what the machines use.