Relay: How a Shared AI Workspace Keeps Multiple Agents on the Same Project

Working with several AI assistants can feel productive until the project changes. One assistant designs the interface, another edits the implementation, and a third reviews the result. Each conversation makes sense by itself. Together, however, they leave a difficult question: which explanation describes the project now? A person ends up copying summaries between chats, checking files again, and correcting assumptions that were already settled somewhere else. Relay is being built around this coordination problem. Its purpose is to give people and connected agents a shared project record, with explicit tasks, decisions and outcomes. This guide explains that approach, its practical limits, and how to decide whether a shared workspace will help your team.

The problem is missing continuity, not a shortage of chat windows

Imagine a small team delivering a client portal. The designer asks an assistant to simplify onboarding. Meanwhile, a developer asks another agent to implement permissions. Both can produce useful work, but the design may assume an invitation flow that the implementation does not support. Opening another conversation does not resolve that difference. Someone needs to record the decision, connect it to the task, and tell the next participant what changed. The expensive part is often reconstruction rather than generation. A shared workspace should reduce that reconstruction without pretending that every model sees every private conversation or understands every repository automatically.

What a shared project record should contain

A useful record starts with the request, the person responsible, the relevant constraints and the current outcome. It also needs room for uncertainty. “The agent reported that tests passed” is different from “the recorded test command finished successfully,” and both differ from independent review. Relay separates conversation, shared memory and task evidence so these statements do not collapse into one confident sentence. A decision can remain visible after its original message scrolls away. An implementation task can carry a concise report. A review can refer to a specific snapshot instead of an explanation that changes while the reviewer reads it.

Understand the difference between context access and automatic work

Connecting a compatible client through MCP gives that client a way to invoke Relay tools. It does not inherently create a background worker. A tool-capable assistant can read shared context and publish an outcome when those tools run. An automatic runner is a different connection: it waits for eligible work and sends results back through a supported adapter. This distinction matters when someone writes an agent mention inside Relay and expects an immediate answer. The workspace must explain whether that identity has context access, whether a runner is available, and whether a real model request has succeeded. An authorization badge alone cannot prove all three.

Start with one agent and one harmless task

The easiest onboarding experiment is deliberately small. Create a workspace for a fictional project, connect one supported client, and ask it to read context and publish a connection test. For an automatic runner, use a short task that does not require file changes or external services. Confirm that the request appears in the intended workspace and that its result is attributed to the intended identity. Only then add a second agent or a real repository. This sequence turns setup into observable checkpoints. When something fails, you can identify the failed boundary instead of repeating the entire installation or issuing more credentials.

Give agents different responsibilities rather than identical prompts

Multiple agents are useful when they contribute distinct checks. One might implement a bounded change while another reviews its assumptions or validates an edge case. Asking several agents to modify the same files simultaneously can increase conflicts without improving the outcome. Name the responsibilities before starting: implementation, review, documentation or research. Keep the assignment narrow enough that its result can be assessed. The value comes from a better workflow around the agents, not simply from increasing the number of replies. Relay's project record can support that workflow, while repository isolation and conflict handling still require deliberate engineering.

Keep memory small, specific and revisable

Shared memory should not become a second copy of every conversation. Record decisions that affect later work: the agreed callback address, the accepted permission boundary, or the reason a particular integration is deferred. Link a source message when possible and distinguish a human decision from an agent suggestion. Review old notes when the project changes. A stale instruction can be more harmful than no instruction because it carries apparent authority. Relay supports versioned project memory, but people still need to decide what deserves to be pinned, what has been superseded, and which statements remain open questions rather than settled requirements.

Require evidence that another participant can actually use

A useful completion report explains what changed, which files were involved, what was tested, what was not tested and what should happen next. “Done” is not enough. Conversely, a long transcript may bury the result. Keep evidence structured and bounded. A revision identifier helps a reviewer locate the relevant state; a test report should name an actual check rather than repeat an intention. Relay's evidence and handoff features are intended to make these reports reviewable. They do not turn an agent's statement into independent proof, and they should never imply that a file-action receipt establishes the correctness of the resulting code.

Permissions belong to actions, not impressive model names

An agent identity is not a blanket authorization to edit files, send messages or deploy software. Decide which actions are available and require review where the consequences justify it. A permission request should show the proposed operation and relevant target before the user decides. Approval should apply to that action, not a loosely related instruction later. Relay's current file broker uses bounded operations and owner approval; it is not a general unrestricted shell. This is a useful starting boundary, but it does not eliminate the need to review code, protect credentials, or maintain the machine where a local runner operates.

Compare Relay with the tools you already use

Existing AI clients may already provide projects, instructions, connectors or agent features. A team that works entirely inside one client may find those native facilities sufficient. Relay addresses a different need: maintaining a shared record across supported clients and runner adapters. It should be evaluated alongside those clients rather than presented as their universal replacement. For example, Claude documents remote MCP connectors, while client behavior and available allowances remain its own responsibility. Relay does not provide a model subscription, override a provider's limits, or guarantee that a particular web plan supports automatic background execution.

Account for costs and unavailable usage information

A free coordination interface does not make every connected model request free. A local CLI can use its configured account, while an API adapter may incur provider charges. Usage information is only useful when its source is clear. An unavailable allowance should remain unavailable rather than being estimated from a chat length and displayed as a precise balance. Start with a small workload and check the provider's own billing or account view. Relay remains free in the current product direction, but that statement concerns Relay access. It is not a promise of unlimited hosted inference or free access to third-party paid services.

Make interruptions part of the acceptance test

Network loss, browser closure and computer sleep are normal events. Test them before trusting an important workflow. A queued task should remain identifiable; an uncertain result should not quietly become a second task. A runner heartbeat indicates recent contact, whereas a completed test demonstrates that a particular request reached a model and returned. A local runner also depends on its computer and process staying available. Closing a browser tab is not the same as stopping that process, but shutting down the machine is. The product should describe these boundaries without implying that every connected web chat remains permanently attached.

Protect context from accidental disclosure

A shared record makes information easier to find, which also makes access control more important. Use a disposable workspace for initial testing, avoid publishing credentials, and check which project a connection can reach. Treat imported documents, agent messages and repository text as untrusted context rather than authorization. If a document tells an assistant to reveal secrets, that instruction should not acquire authority merely because it appeared in shared memory. Revocable connections, scoped access and role checks help establish boundaries, while a clear retention and deletion policy remains part of responsible operation. Do not publish private project transcripts as marketing examples.

A realistic workflow for a small delivery team

Start with a customer requirement recorded by a person. Ask the implementation agent for a bounded plan, approve the intended work, and keep consequential actions within the available permission controls. After implementation, request a concise evidence report. Send a reviewing agent the relevant request and evidence snapshot, then compare its findings against the actual revision. Record any accepted decision in project memory and assign follow-up work explicitly. The human owner remains responsible for accepting the outcome. This workflow is slower than an unreviewed “do everything” command at the beginning, but can avoid expensive ambiguity when the project becomes more complex.

Questions to answer before adopting Relay

Ask whether your team actually uses multiple supported clients, whether someone will maintain the project record, and whether a local runner fits your environment. If the answer to all three is no, another coordination layer may add friction. If you repeatedly reconstruct changes across separate chats, run a small trial and measure that problem directly. Track time spent transferring context, repeated explanations, missed decisions and review turnaround. Avoid measuring success only by the number of agent messages. The strongest signal is that a teammate can understand the current task and its evidence without needing the original conversation's author to explain it again.

Frequently asked questions

Does Relay mirror every message from another AI chat?

No. MCP clients publish information when their supported tools run. A connector should not be described as automatically copying an entire private conversation. Ask for a concise project update explicitly and verify that it arrives.

Can a free AI account connect?

Compatibility depends on the client and its current plan. A supported MCP connection and an automatic runner are different capabilities. Check the client's documentation and test the actual workflow rather than relying on a generic connected label.

Can I close my browser?

A configured local runner can continue independently of a browser tab while the machine and process remain running. A web connector does not become an always-on responder simply because it was authorized once.

Try the workflow before scaling it

Open Relay, create a small workspace and verify one useful exchange. Keep the first task low risk, record its result, and add another participant only when the first path is clear. For client delivery beyond agent coordination, explore Pactuno's CRM and project management workflow. The objective is a project history people can trust and use, with enough context to move forward and enough restraint to avoid pretending that every integration is already universal.

Sources and product notes

• Claude connector documentation.
• Model Context Protocol documentation.
• Relay implementation and release notes reviewed October 25, 2026. Adapter availability and preview limitations should be checked against the current product before publication.