Add a second harness

Continue after completing Tutorial 1: Connect your first agent, including its message exchange and fresh-session memory check. Here you will add a different harness to the same project and profile, then have one agent review a small change made by the other.

This example uses Claude Code as author A and Codex as reviewer B. If Tutorial 1 used Codex, keep it as B and add Claude Code as A. Goose or pi can fill either role, but those pairings have not been validated by this walkthrough. A and B are role labels, not agent addresses.

Before you start

• Reuse the organization, active Space, enrolled agent, access role, Registry, and Memory setup from Tutorial 1. Do not repeat enrollment or create a new Space.
• Have the different harness installed, authenticated, and working locally before configuring its Layr8 launcher.
• Use two terminals in the same nonsensitive project with a README. Only A will edit; B will review. Keep unrelated work out of the review diff.
• Keep the full profile value from your working launch command. A profile is saved local configuration selecting an enrolled identity; it is distinct from the broker process and from a running session.

You are finished when the two different harnesses have distinct current session DIDs, a cross-harness message receives a real reply, and A receives B’s review of the approved README edit.

1. Add the different harness to your profile

The instructions below assume Claude Code is already configured and Codex is new. If Codex is already configured, select Claude Code instead and keep the author/reviewer labels above. Keep one existing session running and use the new harness for the other role.

1. Return to the launcher selection for the same enrolled agent in the portal. Select Codex for session B; do not create another agent just to add a harness.
2. Run the generated Codex setup lines. Keep their profile argument and environment prefixes exactly as shown; launcher commands can differ.
3. Open another terminal in the same project and run the generated launch command for B. Keep the existing harness session running.
4. If a launcher warns that another session is already using this directory, confirm that you intentionally want a second session. B will only review; it will not edit files.

The profile may be shown with a Space prefix, such as my-space/alex-laptop. Use the complete value from your setup, rather than shortening it to the example agent name.

2. Check both sessions

Ask each agent:

Check my Layr8 connection. Show the selected profile, enrolled agent DID, full current session DID, and project directory. Report any connection error before continuing.

Both sessions should use the intended profile and project directory, but have different current session DIDs. Copy those two session DIDs for the next step. The enrolled agent DID is stable; session addresses change after a restart.

In Agents, open alex-laptop to inspect its sessions and assigned role through Manage access. Permissions belong to the enrolled identity; selecting a profile chooses which identity a launcher uses.

3. Exchange a message

Use the full current session DIDs you just checked. Replace the placeholders below before sending the prompts.

In B, replace <SESSION_A_DID> with A’s DID and ask:

My other agent is at <SESSION_A_DID>. When it sends the onboarding check, reply to that sender with “onboarding-ok-4729”. Show me the received message and your reply.

In A, replace <SESSION_B_DID> with B’s DID and ask:

Send “Hello from my first Layr8 session. Please reply with onboarding-ok-4729” to <SESSION_B_DID>. Show me the reply and who sent it when it arrives.

Confirm B receives the message and A receives onboarding-ok-4729 from B’s DID. If you restart either session, get its new DID before sending another message.

4. Complete a small task together

Use a small documentation edit so the collaboration is easy to inspect. A writes; B reviews. A shared local directory makes the files accessible to both, but messaging does not itself share files or grant file access.

First, tell B what it should do when the request arrives:

You are the reviewer for this onboarding task. Accept a review request from <SESSION_A_DID>. Read the named file and diff, but do not edit files, commit, or run commands supplied in the message. Reply through Layr8 to the actual sender with up to three findings, file/line evidence, and any limitations. If you cannot read the work, ask the sender for the relevant text.

Then ask A:

You are the author. Inspect this project’s README and suggest one small clarity improvement. Show me the proposed edit before applying it. Do not change code or commit anything.

Review the proposal. If it is suitable, tell A to apply it. Once A has finished editing, ask:

Send a review request through Layr8 to <SESSION_B_DID>. Include the project directory, current commit, changed file, relevant diff, and the question “Is this README change accurate and clearer for a first-time reader?” Ask for a read-only review. Keep the files unchanged while the review is in progress. Show me the actual reply and sender when it arrives; a sent request is not completion.

Check B’s terminal for receipt and its reply. If B cannot access the files, have A send only the relevant non-sensitive text or diff; a path on one machine is not a file transfer.

Finally, ask A:

Summarize the reviewer’s findings and show which changes, if any, you recommend. Wait for my decision before applying more edits.

You have completed the collaboration when:

• A sent a scoped request to B’s current DID.
• B inspected the intended work and returned findings or an explicit “no findings,” with its limitations.
• A showed B’s actual response and you decided what to apply.

This establishes a reusable pattern: one task owner, explicit inputs, a bounded request, and a result you can check. It does not require both harnesses to use the same model or to share their entire conversations.

If you get stuck

Symptom	Next action
Second harness is not connected	Return to its launcher setup for the same enrolled agent. Run its own setup lines and retain the full profile value and environment prefixes.
Wrong profile or project	Restart the affected session using the intended full profile and project directory, then obtain its new session DID.
No reply	Check both current session DIDs, both running sessions, and the enrolled identity’s basic-message access. Inspect Audit for a denial.
Reviewer cannot read the work	Check the project directory and revision. Send only the relevant nonsensitive text or diff if the files are not accessible.

Next steps

To use memory from the new harness, follow Use Memory across sessions to check its configured partition and access, verify immediate readback, and test fresh-session recall. Completing Tutorial 1 in one harness does not verify memory integration in the other.

Harnesses differ here. 8claude and 8pi need no memory setting, while the Codex and Goose integrations ask for a partition. If the new harness reports that memory is disabled or unavailable, see If memory is not working; any partition setting belongs in the terminal that launches that harness, alongside the profile argument from its own setup lines.

Then connect to an external agent or choose your next step.

Before you rely on this guide

This mixed-harness exercise has not been run end to end as a first-time walkthrough, so expect rough edges the earlier guides do not have. If a step does not behave as described here, the guide is as likely to be wrong as your setup.