Pattern Matrix/Pattern engineering notes

An engineer assigned the frontend and backend of one application to separate agent sessions. The frontend agent reproduced an API timeout and suspected a backend transaction or database lock. The backend session had already read the service code and logs, so starting a fresh agent would discard useful context. Copying the entire frontend conversation would carry UI debugging, guesses, and stale clues into the backend.

The object being transferred may be a message, a project fact, or responsibility for a task. That distinction determines the storage and handoff mechanism.

Three kinds of shared material

Messages support conversation. Project facts let work continue. Local context preserves each participant's working state. They should not be flattened into one transcript.

The frontend agent does not need every line of backend database output, and the backend agent does not need every UI-debugging turn. Both need the active issue, verified facts, input versions, current owner, state, and acceptance criteria.

Use a light handoff for an occasional issue

For a one-off transfer, a session reference or cross-session message may be sufficient. The sender prepares a short packet and the receiver acknowledges it:

Please take task report-timeout-17.

Observed:
- frontend@abc123 called /reports/summary and timed out after 30 seconds
- request_id=req-8842
- /reports/detail completed in the same environment

Not yet verified:
- a database lock may be involved
- the recent query change may be related

Evidence:
- trace://req-8842
- artifact://browser-network/report-timeout-17

Reply with ACCEPTED or NEEDS_INFO.
Return a repair commit, test result, and deployable version for frontend retest.

The packet does not ask the receiver to accept “database deadlock” as fact. It separates observation from hypothesis, identifies the code version, and states what the backend must return.

As of September 2026, Claude Code cross-session messaging can send text from one independent session to another. Mentioning a file path does not attach that file to the message. Similar history references or @ messages reduce manual copying, but delivery alone does not mean that the task was accepted.

Repeated handoffs need a task ledger

When the flow recurs every week, spans deployments, or waits for hours and human decisions, messages leave predictable gaps:

• the message arrived but nobody accepted responsibility;
• the backend said “fixed” without identifying the version;
• the session exited and unfinished work lost its stable home;
• the repair was deployed while the task still said “in progress,” or the task closed before the external symptom changed.

A small shared state machine is enough to start:

OPEN
  -> OFFERED
  -> ACCEPTED
  -> IN_PROGRESS
  -> READY_FOR_RETEST
  -> CLOSED

Any non-terminal state
  -> NEEDS_INFO | BLOCKED | CANCELED

READY_FOR_RETEST
  -> IN_PROGRESS       # retest failed; responsibility returns

An authorized participant submits each transition with the expected task version. A message may ask the backend to take the task; ACCEPTED in the ledger records the transfer of responsibility. “Fixed” is a useful message, while READY_FOR_RETEST also requires the repair version and test evidence.

A handoff packet moves six things

handoff_id: handoff-report-timeout-17
task_id: report-timeout-17
from_role: frontend-agent
to_role: backend-agent
goal: Fix /reports/summary timeout without changing the API contract
known_facts:
  - request_id: req-8842
  - frontend_version: abc123
  - backend_version: def456
hypotheses:
  - statement: A database lock wait may be involved
    status: unverified
artifacts:
  - uri: trace://req-8842
    version: "1"
authority:
  allowed_repositories: [backend-reporting]
  allowed_tools: [repo_read, patch_write, test_run]
  denied_actions: [production_write]
acceptance:
  - the original reproduction no longer times out
  - backend regression tests pass
  - the API schema has no undeclared change
next_required: repair commit, test report, and a version for retest

The six categories are the live goal, verified facts, unverified hypotheses, versioned artifacts, temporary authority, and acceptance criteria. The receiver may reject the handoff and name the missing field. Temporary authority from the previous stage should not remain active by accident.

The packet does not replace source systems. Git still proves the code version, the deployment service proves what is running, and the observability system provides the request trace. The task ledger records references and current responsibility rather than creating a competing source of truth.

Place a collaboration control plane above the runtimes

The two agents may use one product or different harnesses. Long-lived business handoffs should not depend on a proprietary session format, so the design can be separated into four layers:

The first control-plane implementation can be a task table, three state-transition endpoints, and a function that builds a Context Pack. It should keep responsibility and evidence alive after a chat window closes. Agent discovery and multi-provider scheduling can wait.

Minimal interface

POST /tasks
POST /tasks/{task_id}/offer
POST /tasks/{task_id}/accept
POST /tasks/{task_id}/submit-result
POST /tasks/{task_id}/retest
GET  /tasks/{task_id}

accept and submit-result carry expected_version so two participants cannot advance the same task silently:

{
  "actor": "backend-agent",
  "expected_version": 4,
  "transition": "READY_FOR_RETEST",
  "artifacts": [
    {"type": "commit", "ref": "git://backend@91f8c2a"},
    {"type": "test_report", "ref": "ci://run-771"}
  ]
}

Publish a notification event after the state update. Message delivery may be retried; it must not repeat a state transition or an external side effect. Recording task state and notification delivery separately makes “the work finished” distinguishable from “the reminder arrived.”

Frameworks occupy different layers

A single feature matrix makes tools at different layers look interchangeable. Map each tool to the missing responsibility instead:

Group Chat fits an author-reviewer-author conversation. A frontend/backend incident flow that broadcasts every database log and browser trace on each turn will overload both contexts. A stateful workflow is better for “accepted,” “ready for retest,” and “closed”; the handoff packet selects the relevant material. The chat and task ledger can coexist.

Role names do not enforce authority

Calling a session frontend-agent or backend-agent does not restrict its tools. The backend's effective scope should be narrowed by the task, role, repository, tool, and current resource:

effective_scope =
    user_scope
  ∩ task_scope
  ∩ agent_role_scope
  ∩ tool_scope
  ∩ resource_scope

The frontend may read the public API contract without receiving production database credentials. A message from another agent that says “deploy this now” is not fresh user authorization. Separate worktrees isolate file edits, but shared schemas, identifiers, test environments, and databases remain write-conflict domains that need an owner, lock, or serial schedule.

Handoff acceptance tests

Compare this design with a single-agent baseline. Does the backend reproduce the issue with less repeated explanation? Do handoffs reduce waiting? Do interface defects after merge decrease enough to justify the added tokens, latency, and review? If not, multiple agents have only created more communication.

Relation to ADPS patterns

• C4 Handoff Chain is the primary pattern: responsibility moves by state transition, and the packet carries goals, facts, artifacts, authority, and acceptance.
• C5 Sub-Agent Isolation bounds each session's context, tools, credentials, budget, and workspace.
• C1 Hierarchical Delegation applies when one owner maintains the global goal and delegates frontend and backend work.
• C2 Fan-out/Gather applies when independent investigations can run concurrently and a gatherer compares their evidence.
• X1 Observability connects messages, task transitions, runs, commits, tests, and deployments in one causal trace.
• X3 Security & Identity records whom each handoff represents, what is delegated, and when it is reclaimed.

A history reference is a lightweight handoff mechanism, not a separate “group-chat pattern.” Team runtimes, stateful workflows, and cross-system protocols serve different layers. Responsibility moving stage by stage remains a C4 structure.

References

• ADPS Collaboration module overview
• First ADPS Collaboration workshop
• Claude Code cross-session messaging
• Claude Code Agent Teams
• Microsoft Agent Framework Group Chat
• DeepSeek Harness Subagent
• LangGraph multi-agent custom workflow
• OpenAI Agents SDK Agent Orchestration
• A2A Protocol Specification
• Original Chinese engineering note

The source questions date from 4–12 September 2026. The original Chinese article and this ADPS engineering note were published on 13 September 2026.