vigoo's software development blog

Golem 1.5 features - Part 11: Bridge libraries

Posted on April 20, 2026

Introduction

I am writing a series of short posts showcasing the new features of Golem 1.5, to be released at the end of April, 2026. The episodes of this series will be short and assume the reader knows what Golem is. Check my other Golem-related posts for more information!

Parts released so far:

Calling agents from outside of Golem

There are multiple ways to create and invoke Golem agents from outside of Golem. It is possible to expose agents through HTTP or MCP, to use the CLI or the new REPL, or just use Golem's own REST API directly.

With Golem 1.5 we added one more way to this list: generating bridge libraries. A bridge library is a self-contained Rust crate or TypeScript npm package implementing a fully type-safe client for a specific agent, to be used in non-golem applications. The Rust crate is built on reqwest for making requests to Golem's REST API under the hood, while the TypeScript one uses fetch.

Note that due to time constraints, Golem 1.5 will not have bridge generators for Scala and MoonBit as a target language, but we will add them in a future release. This means that it is possible to generate a Rust or TypeScript library to work with agents written in Scala or MoonBit, but it is not possible to generate a Scala or MoonBit library yet.

Enabling the bridge generator

Generating these bridge libraries can be enabled per-agent and per language. The following example enables generating a TypeScript package to call the CounterAgent, and one Rust crate for every agent in the project:

bridge:
  ts:
    agents: 
      - CounterAgent
  rust: 
    agents: "*"

After running golem build, the generated bridges are in the golem-temp directory:

Using the bridge libraries

The generated libraries follow the same conventions as our agent-to-agent communication implementation: there is a type matching the agent type's name with static constructor methods such as get (upserts a Golem agent identified by its constructor parameters), and getPhantom/newPhantom for phantom agents. There are also variants for overriding configuration.

The following example demonstrates how to call the default template's simple counter agent from arbitrary Rust and TypeScript applications using the generated bridges:

import {
  CounterAgent,
  configure,
} from 'counter-agent-client/counter-agent-client.js'

configure({
  server: { type: 'local' },
  application: 'bridgetest',
  environment: 'local'
})

const c1 = await CounterAgent.get('c1')
const value = await c1.increment()
use counter_agent_client::CounterAgent;
use golem_client::bridge::GolemServer;

CounterAgent::configure(
    GolemServer::Local,
    "bridgetest",
    "local"
);

let c1 = CounterAgent::get("c1").await?;
let value = c1.increment().await?;

In the configuration call we have to specify which Golem server to connect to - Local is the default local golem server run instance, but it can also connect to our hosted Cloud or to any custom deployment. The second parameter is the application name (can be found in the app: key of golem.yaml), and the third is the environment name (there can be multiple environments on the same server for an application, for example staging and prod).

Although not demonstrated by this simple example, these generated libraries are fully type-safe, defining all the custom data types used in the parameter list or return type of the agent methods.

Method variants

Just like with agent-to-agent communication, each agent method has multiple variants in the generated client. The default, matching the agent method's name, invokes the method and awaits its result. There is also a way to just trigger the invocation without awaiting it, or to schedule it to be called at a given point in time.