Claude Mods Case Study: Coordinate Two AI Sessions Step by Step

Can two Claude Code sessions collaborate on a website update while a mod routes a small task to a cheaper model and shows what is happening? This worked case study explains how to design that workflow, try it on a small practice project, and check the result.

The project is a fictional software catalog with three problems: inconsistent price data, incorrect price labels, and a layout that needs mobile repair. You will separate the work, establish a message handoff, add a custom coordination mod, and verify the combined changes.

Evidence status: This is a teaching case, not a report of a real client deployment. The included starter and reference solution were checked locally with Node. The live Claude sessions, custom mod, browser rendering, and cost savings were not tested. The kit includes a mod build specification, not a prebuilt executable mod.

What You Will Learn

By completing the exercise, you should be able to:

• Give two sessions separate responsibilities and exchange a useful handoff.

• Route one explicitly defined, read-only worker to a cheaper model.

• Distinguish observed activity, a worker’s completion report, and verified results.

• Integrate changes and measure whether the workflow was worth the coordination effort.

These are related capabilities. Native Claude Code messaging handles communication. A custom mod can add routing rules and a visual interface around the workflow. Installing a mod does not automatically supply the complete system.

Related Contents:

Is Anthropic Publicly Traded?

OpenAI vs Anthropic (2026)

The Case: Repair a Small Catalog Without Losing Track of the Work

The practice page lists Tool A, Tool B, and Tool C. These are fictional products; the prices are illustrative.

Keep the task small enough to inspect. The exercise teaches coordination; it does not claim that two sessions are necessary for a three-product page. On a real project, use this approach only when work has separable parts and dependencies worth coordinating.

Before You Start

Download the practice kit and extract it. You will find claude-mods-lab/starter, reference-solution, MOD_BUILD_SPEC.md, RESULTS_TEMPLATE.md, and a folder of recorded fixture checks.

You need Git, a current Node.js release with its built-in test runner, Python 3 for the local server, and authenticated Claude Code on the same computer. A configured Git commit identity is needed for the branch exercise.

Check the tools in your terminal:

git --version

node --version

python3 --version

claude --version

Use a current Claude Code version. The mods overview lists terminal support from v2.1.287. Individual APIs can have later requirements, so the mod must use the type declarations provided by your installed build.

Keep the reference solution closed until you have finished. It is an answer key, not context the agents need to solve the exercise.

Step 1: Establish a Baseline Before Asking AI to Change Anything

In the extracted starter directory, run:

cd claude-mods-lab/starter

node --test tests/acceptance.test.mjs

Expected starter result: one passing check and three failing checks. This is intentional. The failures identify the data and formatting behavior that must change.

Read CONTRACT.md. It defines the agreed fields, display strings, file ownership, and manual browser checks. Keep this contract and the tests unchanged during the exercise.

This prevents a common failure: the assistant declares success after editing files, but nobody has agreed on what success means.

Step 2: Give Each Session Its Own Checkout

From starter, create a repository and two worktrees:

git init -b case-main

git add .

git commit -m "Add CASE-01 starter"

git worktree add -b case-data ../data-work

git worktree add -b case-ui ../ui-work

Run these commands in a fresh copy of the kit. Git’s worktree documentation explains how separate working directories can share one repository while checking out different branches.

Assign ownership:

The original starter checkout is the integration area. Neither worker merges into it. The person following the exercise reviews and combines the commits there.

These ownership rules are instructions, not filesystem permission enforcement. Worktrees reduce accidental overlap; they do not prevent a worker from accessing other paths.

Step 3: Start and Name Two Sessions

Open a terminal in data-work:

claude --name case-data

Open a second terminal in ui-work:

claude --name case-ui

These flags are documented in the Claude Code CLI reference. They name sessions; they do not create an agent team or synchronize context.

Give each session the same opening instruction:

Read CONTRACT.md and the files relevant to this task. This is CASE-01. Explain your assignment and the checks that apply. Do not edit yet. Do not inspect ../reference-solution. Keep the tests and contract unchanged. Do not publish, merge, or change permission settings.

Checkpoint: Each session should explain its own responsibility and identify the boundary between its work and the other session’s work.

Step 4: Prove the Message Handoff Works

Inside case-ui, run:

/list-agents

Confirm that case-data is a reachable target. If names are ambiguous, use the identifier from the listing.

Then ask:

Send case-data this request: “CASE-01 contract check: confirm the target price field, its value type, and the missing-price behavior. Reply with CASE-01-CONTRACT-ACK. Do not edit yet.” Show me the response when it arrives.

In case-data, approve or handle an inbound message if the session requires it, and ask it to answer the request. Confirm the reply in case-ui before proceeding.

The cross-session messaging documentation explains delivery and inbound controls. Messages contain text, not the sender’s full conversation or attached files. A queued message is not proof that another session acted on it.

Checkpoint: You have a task-specific acknowledgment containing monthly_usd, numeric-or-null values, and Contact sales for an unavailable price.

If messaging fails, resolve the listed availability or inbound-control issue first. Do not hide it behind a dashboard that simply assumes delivery.

Step 5: Build a Small Mod Around the Proven Workflow

The next layer adds coordination visibility and one routing policy. It should not replace the working communication mechanism.

In case-ui, paste:

Read ../MOD_BUILD_SPEC.md. Use your plugin-authoring guidance and the type declarations for this installed Claude Code version to implement the specification. Save a persistent plugin at ../mods/case-observer. Include its README, read-only catalog-audit subagent, hooks module, and meaningful tests. Explain any unsupported requirement. Run validation and tests. Show me the filesystem, process, network, and model calls before I load it. Do not claim it works in two sessions until we demonstrate that.

The specification defines selected session IDs, a bounded message format, an acknowledgment rule, routing eligibility, and evidence-based display states. It explicitly excludes deployment and automatic merging.

The mod creation guide explains generation, approval, and persistence. Follow actual prompts in your installation. Do not rely on a generated mod remaining in a temporary session folder.

Checkpoint: You have real plugin files, a validation report, and test results—not just a description of a proposed plugin.

Step 6: Load the Same Plugin in Both Sessions

Once you have reviewed the plugin and the relevant sessions are idle, exit them and resume with the persistent directory loaded.

From data-work:

claude --resume case-data --plugin-dir ../mods/case-observer

From ui-work:

claude --resume case-ui --plugin-dir ../mods/case-observer

Use /plugin to inspect loading. Configure the actual target session IDs as the plugin README instructs; a display name alone should not silently select an ambiguous target.

Both processes load the same code, but they do not automatically share runtime memory. Remote status must arrive through explicit messages or another documented integration.

Ask for one status round trip. If the plugin cannot report a reliable state, its display should say unknown. The mods API documents sending messages and observing message events.

Step 7: Demonstrate One Cheaper-Model Assignment

The first routed worker has a narrow job: inspect the catalog schema and report references to the legacy field. It cannot edit files.

Ask case-ui:

Start one fresh catalog-audit subagent for CASE-01. It should inventory the current data keys and value types and locate references to monthly_price. Do not let it edit. Show the model selected by the routing policy and its reason. If the configured cheaper model is unavailable, report that instead of silently choosing an expensive fallback.

The mods reference documents changing the selected model through agent.spawn. The specification requires matching only the explicitly named worker. Other workers retain their original selection. Resuming an existing subagent does not rerun the spawn-time rule.

Checkpoint: The routing event selected the configured model, and the fresh worker returned the requested inventory. Treat model selection and completed execution as separate observations.

This demonstrates policy application, not cost savings. A deterministic search could perform this small inventory without an LLM. In a real workflow, use ordinary code when it is the simpler, cheaper solution.

Step 8: Repair the Data and Interface in Parallel

Give case-data its assignment:

Complete DATA-01. Change only data/products.json to the agreed monthly_usd contract. Preserve product IDs, names, currency, and features. Values must be 12, 25, and null in the existing order. Remove monthly_price. Run the relevant checks and report remaining failures honestly. Commit only your assigned file. Send case-ui the actual commit identifier and contract summary. Wait for acknowledgment.

Give case-ui its assignment:

Complete UI-01. Change only src/catalog.mjs and styles.css. Format the agreed monthly_usd values as specified in CONTRACT.md. A null price is Contact sales; a genuine zero stays $0.00 / month. Repair the forced-width layout for the stated viewport checks. Keep tests unchanged. Run checks, commit only your assigned files, and record remaining verification work.

Some checks may fail in each isolated worktree because the other branch’s change is absent. That is expected; do not “repair” the tests or secretly copy another worker’s files to produce a green report.

Checkpoint: Each commit touches only its assigned paths, and the data handoff identifies the actual schema and commit. A commit identifier makes the handoff inspectable.

Step 9: Read the Dashboard as Evidence, Not Reassurance

The interface guide documents the building blocks for a custom pane. Our specification asks the generated mod to distinguish these states:

A UI worktree passing formatting checks does not establish that the integrated catalog works. A node saying “verified” must identify what was checked and against which code state.

Ask the mod to demonstrate three cases: a message queued without acknowledgment, a failed or denied edit, and a passing check followed by a relevant file change. The state should remain uncertain, record the attempt appropriately, or become stale.

The pane shows activity and evidence. It does not expose hidden model reasoning.

Step 10: Combine the Commits and Check the Actual Page

Return to the original starter directory in a separate terminal. Inspect each worker’s commit before integration:

git show --stat case-data

git show --stat case-ui

git status --short

Once reviewed, apply the actual worker commit IDs:

git cherry-pick DATA_COMMIT

git cherry-pick UI_COMMIT

node --test tests/acceptance.test.mjs

DATA_COMMIT and UI_COMMIT are placeholders: replace them with the actual hashes. If a worker produced several commits, inspect and apply the intended sequence. Resolve conflicts deliberately rather than assuming messaging merged anything.

Expected acceptance result for a correct combined solution: four passing checks.

Serve the integrated page:

python3 -m http.server 8000 --bind 127.0.0.1

Open http://127.0.0.1:8000. At 390px and 1280px, inspect the three cards, horizontal overflow, wrapping, and the exact price labels. Check the browser console and data-loading error state. Opening the HTML directly is insufficient because the page fetches a JSON file.

Record the final commit or code fingerprint with the evidence. A later relevant edit requires the affected checks to run again.

Step 11: Record Results and Decide Whether to Keep the Workflow

Use RESULTS_TEMPLATE.md. Record the message acknowledgment, actual worker model, failed attempts, final checks, browser observations, and any attributable usage.

For this published teaching fixture, the observed local results were:

The reference solution was prepared directly for the kit. The Git walkthrough was checked by applying those prepared patches on separate branches and combining their commits. These results show that the exercise is internally consistent and its data and formatter meet the defined checks. They do not demonstrate that Claude performed the work or that the multi-session workflow saved money.

To evaluate savings, compare similar tasks at the same acceptance standard. Include model usage, retries, coordination, review time, and mod maintenance. With an API, price the measured usage using applicable rates. With a subscription, record allowance consumption and any extra charges rather than inventing a dollar cost for each task.

The useful metric is cost and time per accepted result. A cheaper worker that repeatedly needs repair may increase both.

What This Case Teaches

Separate work before adding workers. A shared objective is not enough; each assignment needs an owner, input, output, and acceptance condition.

Make handoffs inspectable. Include a task identifier, schema or decision, commit, and acknowledgment. Messages coordinate work; they do not synchronize all context or combine code.

Route bounded jobs and verify them. Use an explicit eligibility policy. Keep ambiguous work with the appropriate reviewer and make fallback behavior visible.

Build supervision around evidence. “Started,” “reported complete,” and “verified” should remain distinct. The status must become stale when its supporting code changes.

For the smallest jobs, one session and a clear test may be enough. Keep the custom workflow when it solves repeated coordination problems more effectively than that baseline.

Frequently Asked Questions

Is an Executable Claude Mod Included?

No. The kit includes a detailed build specification that Claude Code can implement against the installed API. It also includes the starter project, acceptance checks, recorded fixture outputs, and reference solution.

Can I Follow the Exercise Without Building the Mod?

You can practice the two-session messaging and Git handoff first, then add the routing and dashboard layer. Label that first run as native messaging, not a validated mods experiment.

Does the Dashboard Enforce Access Restrictions?

No. A display is not a sandbox. The administration guide explains the distinction between managed controls and a mod’s own access. Review generated code and requested capabilities before loading it.

What Should I Publish as the Case Study’s Outcome?

Publish the measurements you actually recorded and explain their scope. If only local fixture checks were performed, report those. A real claim about collaboration quality, reliability, or savings requires a live run and a suitable comparison.

Teaching case with a downloadable practice kit. Fixture verification is documented separately from untested Claude and browser behavior.