At 4:40 p.m., one assistant has compared three caching approaches and helped you choose one. The branch is still empty. You want a second assistant with repository access to implement the choice, then perhaps return to the first for review. Pasting the whole planning chat would bury the decision under discarded ideas.
Hand over the engineering state that survived the discussion, not the discussion itself.
Split the work by the evidence it should produce
A useful split gives each assistant a bounded job:
- Research: locate the relevant code, documentation, and constraints. Its output is a sourced map, not a recommendation you must trust.
- Plan: turn that map into an implementation sequence, including migrations, compatibility concerns, and tests.
- Code: work against the named repository state and produce a diff plus test output.
- Review: inspect the diff against the agreed constraints and look for missed cases.
These roles can move between assistants. The important boundary is the artifact each stage must leave. “We discussed retries” is not enough. “Keep the existing retry policy; add coverage for a dropped connection before login” gives the next assistant something checkable.
Build a briefing that points to the repository
RelayLink does not carry a repository, terminal, browser state, or test process. Put stable text references in the briefing:
- repository and branch, or the exact commit under review;
- relevant file paths and symbols;
- the behavior that must remain unchanged;
- the chosen approach and why the alternatives were rejected;
- commands already run, with pass, fail, and skipped results;
- open risks and the next decision you want.
Do not report “tests pass” when only a narrow test ran. Name it. If a failure is environmental, preserve the failure text and say what evidence supports that diagnosis. The destination assistant still needs its own authorized repository and tool access; a path in a briefing grants nothing.
Send the implementation state to yourself
Connect your assistants to the same RelayLink account, then address the package to your own email. A self-handoff uses one account and one participant. It creates no contact request, sends no email or magic-link page, and needs no second account.
The workflow still has three deliberate steps: draft, review, confirm. Your model never sends autonomously. Check the package for secrets, stale paths, invented test results, and private scratch notes before confirming it.
The package then appears as unread inbound until one of your assistants pulls it. If no assistant is available, the account portal is the fallback. RelayLink carries the selected, human-approved briefing; it does not synchronize either assistant’s context.
Make review independent
A second model is another opinion, not proof. Give the reviewer the diff or commit and the original acceptance criteria through its own authorized repository access. Ask it to challenge a specific risk: concurrency, authorization, backward compatibility, failure recovery, or test adequacy.
When assistants disagree, preserve both claims and the evidence each cites. Resolve the disagreement by checking code, documentation, and executable tests. Do not let confidence or length choose the winner.
When this workflow is a poor fit
Do not hand off work when the second assistant cannot inspect the same repository state or run the relevant checks. Keep live debugging with the assistant that can see the process when the missing fact is in memory, a terminal, or a browser session.
Company and repository policies also remain in force. If a provider is not approved for the source, logs, customer data, or vulnerability details involved, remove that material or stop. RelayLink approval records your decision to send a briefing; it does not authorize either AI to receive the underlying code.