How does it work?
Connected work. Clear boundaries.
Relay brings your work into a shared model, so a note can connect to a person, a project, a meeting or the next thing to do. Here’s the idea behind it—and the directions we’re exploring next.
One connected model
Notes, tasks, people and resources are useful on their own. Connections make them more useful: a meeting belongs to a project, its paper references the people involved, and its next steps remain real tasks. Different views show the same underlying work.
Sharing is explicit. Linking to something doesn’t grant access to it. People and agents can only read or change the work they’re authorized to use.
Connected actions, fewer repeated steps
An agent can propose several related changes as one connected plan: create a project’s tasks, link them to one another, and write the supporting notes. You review the proposal before applying it. Shared commands give the agent a direct way to work with your workspace, which can reduce repeated instructions and context between steps.
What we measured
In an internal synthetic benchmark on September 29, 2026, we compared three workflows in Relay: a composed plan versus a sequential, one-command-at-a-time approach. Both used Mercury 2 with the same proposal profile and medium reasoning. Each workflow was run once per approach, for six successful jobs.
| Workflow | Composed | Sequential |
|---|---|---|
| Create a parent task, five children and a linked description | 13,432 | 107,907 |
| Place thirty existing items in a collection | 17,355 | 17,592 |
| Tag 120 matching tasks and save a summary | 15,434 | 26,382 |
| Total | 46,221 | 151,881 |
The combined total was 69.6% lower with composed commands. This is a reduction in the summed token counts, not an average of three workflow percentages. Most of the difference came from creating linked parent and child tasks. The collection baseline already used a bulk operation and showed little benefit from composition.
We checked saved outcomes: the six tasks and their links, all thirty original collection members without duplicates, and all 120 selected tasks tagged with an accurate saved summary. Excluded work remained unchanged.
What this result does—and doesn’t—show
This is an initial result from generated sample work, not a repeated study of everyday customer use. Token counts vary with the workflow, model, context and retries. Fewer tokens do not establish an equivalent reduction in cost or completion time, or superiority over another agent or product. Broader workflows and repeated runs are needed before treating this as a typical result.
Your devices and your workspace
The workspace keeps the shared record. Supported papers can also have local copies in web and native clients, so edits can be retained through a disconnection and reconciled on reconnect. Offline availability depends on the client, the paper and what has been saved locally.
↕ Authorized access and synchronization
Future direction · conceptual
Independent spaces, an optional shared network
We’re exploring self-hosted Relay instances that an individual or organization could operate independently. Each would control its own data, membership and access. Connecting to the wider network would be a choice, not a requirement to copy private work to Relay Cloud.
↕ Optional · explicitly public information only ↕
Atlas could help people find public resources and organizations across this network. Joining a workspace would still require that organization’s invitation or approval. Discovery would never grant access by itself.
Where Nostr could fit
Nostr is an open protocol for signed events exchanged through relay servers. We’re exploring it for portable public identity, public references and publishing, so selected information could be recognized beyond a single service.
That is a public interoperability layer, not the database for your private workspace. Private notes, relationship records and conversations would not be published to Nostr. Running a Relay instance and running a Nostr relay are different things.
Apps built around your work
Relay already gives authorized integrations and agents ways to work with its shared data. Our longer-term goal is to let you use AI to create specialized Relay apps, with the same permissions and connected context underneath.
We’re also considering open source. There is no committed license, release date or promise that all of Relay will be open source. Self-hosting, network participation and app creation remain areas of exploration; this page describes direction, not a deployment guide or an availability commitment.