Agent Relay: four primitives, four other repositories, no compose file

Four primitives, and three of them are documented in other repositories

The product is presented as four pieces you can use separately or combine.

Messaging is the one that lives here: shared channels, threads, direct messages, files, search and real-time events, with agents able to run on different machines and still coordinate in one workspace. The other three each link out. Integrations, where GitHub, Linear, Notion and Slack are exposed as a virtual filesystem that agents drive with `ls`, `cat`, `grep` and ordinary file writes, is a separate repository, relayfile. Shared Sessions, which captures coding agent sessions so a team and its agents can search past work and decisions, points at two more, relayhistory for how sessions are captured and trajectories for how decisions are captured. Flows, the enforceable multi-step workflows, live in a repository called flows.

So this repository is a hub with a CLI, a shared core and a manifest of primitives. The tree even contains a `.trajectories/` directory, which is the same name as one of the projects it links to.

That shape is a reasonable way to separate an integration from a runtime, and it means an adopter has to follow four codebases to understand one product.

Self hosting is offered by email and the tree has no container recipe

The installation story has two halves, and they are not equally documented.

The quick path is a hosted product: Agent Relay Cloud, which the page points at as the easiest way to get started, needing no credit card and letting you explore all the pieces without setting up any infrastructure. The self-hosting paragraph then says the project has self-hosting options for each primitive, offers to help you set up the whole system in your environment, and gives an email address, hi(at)agentrelay.com.

What the repository contains is not a deployment artefact. The root listing has no Dockerfile, no compose file, no Helm chart, no Terraform and no service definitions. The only scripts that touch installation are `install.sh` and `install.test.sh`, which install the client rather than run the service.

So the promise is real but manual: someone will walk you through it. That is workable for a team with an infrastructure person and a poor fit for an engineer who wants to read a compose file and know what they are running.

The CLI installs as agent-relay and the badge advertises @agent-relay/sdk

Two install commands are offered. One pipes a script straight into a shell:

curl -fsSL https://raw.githubusercontent.com/AgentWorkforce/relay/main/install.sh | bash

The other uses npm:

npm install -g agent-relay

Neither name is the one in the badge row. The npm badge at the top of the README points at `@agent-relay/sdk`, and it appears twice with identical targets. The install command uses the unscoped `agent-relay`. And the root manifest in this repository is `@agent-relay/monorepo`, marked private.

So there are three package names in play: the private monorepo root, the scoped SDK the badge links to, and the unscoped CLI the quick start installs. The repository description for the SDK package is not on this page, so a reader has to work out which artefact they need before running either command.

The pipe-to-shell form is worth a second look independently of the naming. It fetches a script from the default branch at install time, which means the installer is whatever is on main that day rather than a versioned release.

The build is a thirteen step chain, and one script only prints a message

The root manifest shows how a 14 package workspace is built, and the answer is a long chain rather than a task runner.

The core build script is a single line of thirteen invocations, each of which shells into one package with `npm --prefix`: session, config, cloud, utils, policy, sdk, harness-driver, harnesses, integration-prompts, evals, fleet, cli-surface, and finally cli. The typecheck script is a shorter chain of ten of those builds followed by a `tsc --noEmit` run inside `packages/cli`.

Two things stand out. A `turbo.json` sits in the repository root, and none of these scripts call it, so the dependency graph of the workspace is expressed as ordering inside a shell line rather than as a task graph. And one script, `build:packages:watch`, does nothing except print a notice that package watch build was removed with the simplified core surface and to use package-specific watch commands instead. A removed command kept as a message is a small courtesy, but it is still a script a new contributor will try.

The package names in that chain are also the best available inventory of the system: session history, configuration, cloud, utilities, policy, the SDK, a harness driver, harnesses themselves, integration prompts, evals, fleet, a CLI surface, a connect package and the CLI.

TypeScript, Rust and Swift share one repository

GitHub reports TypeScript as the primary language, and the tree is a good deal more multilingual than that.

There is a Rust workspace with two members, `crates/broker` and `crates/relay-pty`, declared with a workspace manifest, a lock file and a `Cross.toml`, which is the configuration for cross-compiling and distributing Rust binaries. A PTY crate is the kind of component you need when an agent drives a terminal session rather than calling an API, and a broker is the kind of component you need when several processes need to reach the same place.

There is also a `Package.swift`, which is a Swift package manifest, and a `.nvmrc` pinning the Node version for the TypeScript side.

So the deployment story is not only containers and npm: there is a Rust binary that gets cross-compiled and a Swift package in the same tree. None of that is described on the page, which covers messaging, integrations, sessions and flows and stops. If you are evaluating this for a macOS or terminal-automation workflow, the interesting parts are the ones the README does not describe.

Three agent instruction files and a skills lock sit in the root

The repository keeps its own agent configuration in version control, and keeps three of them.

There is `AGENTS.md`, `CLAUDE.md` and `GEMINI.md` at the root, plus `.agents/`, `.claude/` and `.openskills/` directories and a `skills-lock.json`. Alongside those sit a `.syncpackrc.json` for dependency version consistency, a `knip.json` for dead-export detection, and a `prpm.json` with `prpm.lock`.

This is worth naming because of what the product is. Agent Relay sells the idea that rules should live in code instead of in a skill or a prompt file that an agent may ignore, and the repository responds by committing its own instructions in three vendor-specific formats and locking its skill set.

That is not a contradiction, since the flows primitive is code and the instruction files are for the humans and agents working on the repository itself. It does mean the root has become a place where several agent ecosystems each expect a file, and a contributor touching behaviour has to decide which of them is authoritative.

TELEMETRY.md and REVIEW_VERDICT.json are committed beside the build config

The root of this repository is unusually honest about its own process, and unusually full.

Alongside the usual configuration sit `TELEMETRY.md`, a document about telemetry; `REVIEW_VERDICT.json`, a machine-readable review outcome; and a `.workflow-artifacts/` directory. Then come the working directories: `learnings/`, `plans/`, `specs/`, `docs/`, `evals/`, `examples/`, `flows/`, `plugins/`, `packages/`, `scripts/` and `tests/`, plus two root-level configuration files for the flows primitive, `flows.json` and `teams.json`.

Some of that is a deliberate choice. Committing learnings and plans means you can read how a decision was reached, and a committed review verdict file is unusual enough to be intentional. The cost is that the root no longer reads as a project layout, and a newcomer has to distinguish configuration the product reads from notes the team writes for itself.

The test surface is more conventional and worth knowing about: a CI workflow, an `evals/` directory, unit and end-to-end vitest configurations, a setup file, and a single TypeScript example at `examples/relay-node.ts`.

Version 13.0.1 arrived with a major bump eleven days before the last push

The release window is short. v12.4.1 was published on 2026-09-22, v13.0.0 on 2026-09-30, and v13.0.1 on 2026-10-02. The manifest version is 13.0.1, so the tags and the package agree, and the last push to the default branch was 2026-10-02.

A major version bump inside that window is worth pausing on for an infrastructure tool, because it implies breaking changes to a messaging surface or a config format that other systems may read. The changelog is in the repository, and there is no upgrade note on the page itself.

One dependency between the primitives is worth flagging, because it is easy to miss. The Shared Sessions plugin can be used from the repository, but the MCP route is documented as connecting with `agent-relay mcp --sessions-only` after Cloud login. So one of the four primitives has a path that runs entirely locally and another that wants an account with the hosted product, and the page does not explain what the session-only mode gives up.

The licence is Apache 2.0, copyright 2026 Agent Workforce Incorporated, which is the most permissive outcome for an infrastructure tool and worth more to an adopter than any of the feature bullets.

Editorial conclusion

Take Agent Relay if your problem is that agents on different machines, or different people, need to talk to each other and leave a searchable record, and you are willing to run the hosted product first. Leave it if you need a self-hosted deployment you can read, because the repository contains no Dockerfile or compose file and self-hosting is offered as help over email, or if you need one repository to audit, since three of the four primitives live elsewhere. Three things to check before adopting it: whether the primitives you actually need are the ones in this repository rather than the sibling projects, whether `npm install -g agent-relay` gives you the CLI you saw on the page, and whether the version, currently 13.0.1 after a major bump on 2026-09-30, matches what your teammates have installed.

Frequently asked questions

Official sources

1. AgentWorkforce/relay on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases