What is Golem?
Golem is an open-source runtime for AI agents. You write an agent as an ordinary class in TypeScript, Rust, Scala, MoonBit, or Go, and deploy it to Golem. Golem runs each agent as a long-lived, isolated instance with its own memory and filesystem, and makes that instance durable: if a process crashes, a server restarts, or you deploy new code, the agent continues from where it was, without repeating work it already finished.
The same deployment also runs the agent’s tools (a shell, file editing, Node.js and npm, the TypeScript compiler, web fetch, and tools you write) and serves what the agent produces, such as a web app, an API, files, or a live stream of output. Golem enforces what each agent is allowed to do, independently of the agent’s code or prompts.
Golem runs on your machine from a single binary, on your own infrastructure, or on Golem Cloud.
Where Golem fits
An AI agent application usually has these parts:
| Part | What it does | In a Golem application |
|---|---|---|
| Model | Generates text and chooses which tools to call | A model provider, called over HTTP |
| Agent loop (also called a harness) | Calls the model, runs the tools it picks, decides when to stop | Your code, or an agent framework for your language, running inside a Golem agent |
| Runtime | Runs the code, keeps its state, isolates it, enforces permissions, serves results | Golem |
| Tools | Run commands, edit files, fetch pages, call services | Golem tools, or remote services the agent calls |
Agent frameworks such as LangChain, the Vercel AI SDK, or Mastra provide the agent loop. Inside Golem, the loop is ordinary agent code in any of Golem’s languages: TypeScript, Rust, Scala, MoonBit, or Go. You can write it yourself or use an agent framework or harness library for your language. In TypeScript, the Vercel AI SDK and TanStack AI are tested inside Golem agents. Golem is the layer underneath: it decides where the loop runs, what happens when it fails, what it may touch, and how its results reach users. Without such a runtime, those concerns are usually spread across a queue, a database for progress, a workflow engine, a sandbox service, and a web server. Coming from another system? Familiar terms maps its vocabulary to Golem’s.
Open full-size image in a new tab.
Open full-size image in a new tab.What Golem provides
Agents with identity. An agent type is a class with state and methods. Each agent is addressed by its type and constructor arguments, such as ReportAgent("acme", "q3"), and Golem creates it the first time it is called. Every later call with the same arguments reaches the same agent and its state. See Agents.
Durable execution. Golem records every interaction an agent has with the outside world, such as HTTP requests, model calls, calls to other agents, tool calls, and clock reads, in a per-agent log called the oplog. After a failure, Golem rebuilds the agent by re-running its code against that log, so the agent ends up with the same memory and files and continues where it stopped. You write no checkpoints, step wrappers, or retry logic. Every tool call executes exactly once. Agent-to-agent calls execute exactly once. Completed model calls are recovered from the oplog rather than requested again. Requests to external services carry an automatic idempotency key, so a request that was in flight during a failure can be sent again safely to services that support such keys. See Durable execution.
Tools. A Golem tool is a typed command, such as bash, npm install, or tsc, that runs in its own WebAssembly sandbox and can work on the calling agent’s filesystem. Your agent loop offers these tools to the model like any other function-calling tool, and Golem runs each call in a sandbox with the agent’s permissions. An agent can write code, install packages, compile, and run the result without a separate container or VM. See Tools.
Permissions. An agent can only do what its permission cards allow: which hosts it may connect to, which files it may delete, which secrets it may read, which tools and agents it may call. Golem checks the cards on every operation, so a prompt or generated code cannot grant itself more access. See Permissions.
Agent communication. Agents call each other through typed clients, across languages. An agent can wait for a person or an external system, for hours or months, and uses no memory while it waits. See Agent communication.
Artifacts. Agent methods can be exposed as HTTP endpoints and MCP tools. The same deployment can serve a web front-end, files the agent writes, and resumable streams of its output. See Artifacts.
A request, end to end
A signed-in user asks a reporting application for a quarterly report:
- The browser sends
POST /reports/acme/q3. Golem checks the user’s login before any agent code runs. - The request reaches
ReportAgent("acme", "q3"), which Golem creates on first use. - The agent’s loop calls a model and runs the
web-fetchandwrite-filetools. The agent’s permission card allows network access only to the model provider and the company’s data API, and the tools write into the agent’s own filesystem. - The agent waits for a manager’s approval. While it waits, Golem unloads it from memory. The wait survives restarts and redeployments.
- After approval, the agent serves the report over HTTP and streams progress to the browser. If the page reloads, the stream resumes.
If a server fails at any step, Golem rebuilds the agent on another server from its oplog. Model calls that already completed are not made again, and no tool call runs twice.
Open full-size image in a new tab.
Open full-size image in a new tab.What you don’t have to build
| Requirement | Typical approach without Golem | With Golem |
|---|---|---|
| Resume an agent after a crash | Save progress to a database and write recovery jobs | Automatic, from the oplog |
| Avoid repeating model and tool calls on retry | Idempotency tables and per-step wrappers | Recorded results are reused |
| Hand work between agents reliably | A message queue and deduplication | Typed calls that execute exactly once |
| Wait days for a human approval | Persist workflow state and handle callbacks | await a promise or webhook |
| Run generated code safely | A container or VM sandbox, plus file syncing | Sandboxed tools on the agent’s filesystem |
| Limit what an agent can do | Checks in application code, rules in prompts | Permission cards enforced by the runtime |
| Show results to users | A separate web server, file hosting, and stream buffering | HTTP endpoints, files, and streams from the same deployment |
When to use Golem
Golem is a good fit when agents:
- run for longer than a single request, or must not lose work when something fails,
- call tools, especially tools that run code or change files,
- wait for people or external events,
- need enforced limits on network, file, secret, and tool access,
- serve results to users through an API or an interactive web front-end backed by the agents.
Many useful agents write and run small programs for their users, even when the users never see code: a support agent that writes a script to reconcile an account, or an analyst agent that installs an npm package, transforms a spreadsheet, and publishes the result as a web page. These agents can run entirely inside Golem: the model loop, a shell, file editing, npm, npx, the TypeScript compiler, and Node.js-compatible execution all run in the runtime, on the agent’s durable filesystem. Golem can host a complete coding agent this way. The same mechanisms support simpler agents, such as chat assistants, report generators, and approval workflows.
Know these boundaries before you start:
- TypeScript agents run on a WebAssembly JavaScript runtime based on QuickJS, not on Node.js. Most npm packages work; packages with native addons do not. Rust, MoonBit, and Go agents compile directly to WebAssembly.
- Tools that need native binaries, Python, Docker, or a full browser run on a remote sandbox or VM that the agent calls. Golem records those calls, not the remote machine’s state.
- There is no Python SDK. Python programs can call Golem agents over the REST API, MCP, or HTTP endpoints.
Where Golem runs
| Option | What it is |
|---|---|
| Local | The golem binary contains the CLI and a complete Golem server: golem server run |
| Self-hosted | Docker images for Docker Compose or Kubernetes |
| Golem Cloud | The hosted service, currently in Developer Preview for evaluation and prototyping |
A self-hosted cluster runs Golem’s services as separate containers (gateway, registry, shard manager, compilation service, and executors) on PostgreSQL, Redis, and S3 or a shared file system. Agents, components, and the CLI behave the same locally and in a cluster. Architecture describes the services and storage in detail.
Golem has SDKs for TypeScript, Effect (TypeScript), Rust, Scala, MoonBit, and Go. It is licensed under BUSL-1.1, and each version converts to Apache-2.0 four years after release. Production use is permitted, including products whose agents run on Golem; the exception is offering Golem itself as a hosted developer platform.