Integrations

Four ways to hand a machine to an agent, one model-agnostic toolkit underneath them, and a catalogue of agents that run on the machine itself.

An integration maps one vendor’s tool vocabulary onto the canonical machine API and nothing more. None of them is an agent framework, none owns a conversation, and none of them can reach a route your own API key cannot.

tool call  ->  adapter  ->  machine api  ->  machine agent  ->  screenshot

The dependency only ever points that way. @raster/sdk does not import any of these packages, and its own tools work with no vendor SDK installed at all.

Or the other direction

The four above hand a machine to an agent running somewhere else. An agent can also run on the machine. Those do not need an adapter at all — they need a computer that stays put — so they ship as published environments rather than as packages here.

Four are in the catalogue today: Claude Code, OpenClaw, Hermes Agent and opencode. Each one is a template any organization can create a machine from. Launching one creates the machine, stores the API key you gave it as a machine secret, installs the agent on first boot, and takes you to it: a terminal already attached for the three that are TUIs, and a published port for OpenClaw, which serves its own UI.

The three TUIs run inside a tmux session, so closing the tab detaches rather than ending the conversation, and opening the machine’s terminal again attaches to the same one.

Nothing about the catalogue is privileged. A published entry is an image, a size, a first-boot setup script and a launch descriptor — the same pieces the OpenClaw page has you assemble by hand, which is exactly why that page is still the reference for building your own.

Or none of them

If your harness is your own, skip the adapters. machine.tools.generic() is eight JSON-schema tools and a dispatcher with no vendor package anywhere in it:

const toolkit = machine.tools.generic();
const result = await toolkit.execute("computer_screenshot", {});

computer_screenshot, computer_click, computer_type, computer_key, computer_scroll, terminal_exec, file_read, file_write. Names, argument shapes and result shapes are a published contract: a field may be added, a meaning may not change.

The vendor adapters cover the GUI. Mixing in one canonical tool — usually terminal_exec — gives the model a shell without a terminal window, and both reach the same machine. Every example in this section does exactly that.

What every integration assumes

• Screenshot before you click. Coordinates are the machine’s current display pixels, and one outside it is refused rather than clamped. Nothing is scaled for the model.
• One machine per task, reused. A machine keeps its filesystem, so creating a fresh one per turn throws away the work.
• A failed action stops the ones queued behind it. A click that failed usually means the screen is not what the model thought, so the rest of that message is answered as not executed rather than applied to the wrong window.
• Close the machine. await machine.close() releases the input lease and the session.