한국어 | English

Peer Sessions

Why Peer Sessions Matter

AGS uses multiple sessions for more than raw parallelism.

Each session can retain its own:

• conversational context,
• responsibility,
• working directory,
• model and execution settings,
• accumulated investigation,
• and verification role.

Peer collaboration preserves that independence while allowing sessions to exchange only the information required for the next decision.

Example Team Structure

                  ┌──────────────┐
                  │ Lead Session │
                  └──────┬───────┘
                         │
             ┌───────────┴───────────┐
             ▼                       ▼
      ┌──────────────┐       ┌──────────────┐
      │ Implementation│◀────▶│ DB / Research │
      │ Codex         │       │ Claude Code   │
      └──────┬───────┘       └──────────────┘
             │
             ▼
      ┌──────────────┐
      │ Independent  │
      │ Audit Session│
      └──────────────┘

If the database session discovers a constraint that affects the API implementation, it can send that condition directly to the implementation session.

The implementation session evaluates the new information in its existing code context.

A separate audit session can then inspect the resulting change from an independent context and return findings without inheriting the implementer's exact reasoning path.

Session Board

The session board is the discovery mechanism for peer collaboration.

An entry can contain:

• host,
• session ID,
• working directory,
• current task summary,
• and update timestamps.

The board is not a real-time messaging channel. It helps a session locate the peer responsible for a task. Actual collaboration content is sent through PEER messaging.

Direct Communication

A PEER message can carry:

• a question,
• a discovered constraint,
• an artifact location,
• a verification reference,
• an audit request,
• a blocker,
• or a work result.

The lead session does not have to become a mandatory relay for every message.

Relevant specialists can communicate directly while the lead continues to manage the global objective and overall state.

Responsibility Separation

Peer structure makes role boundaries explicit.

Role	Typical responsibility
Lead	Goal, scope, priority, overall state
Implementer	Code changes and direct validation
Researcher	External conditions, documentation, data
Auditor	Independent review of result and evidence
Recovery owner	New strategy after a confirmed failure cause

One session can perform several roles when appropriate. For higher-risk or more complex work, separating roles across contexts can increase the value of independent verification.

Peer Sessions and Subagents Can Coexist

Peer architecture does not prohibit subagents.

A peer session can still use subagents internally to parallelize its own responsibility.

Peer Session A
 ├── subagent 1
 └── subagent 2

Peer Session B
 ├── subagent 1
 └── subagent 2

AGS operates above that local delegation structure.

Its main concern is how the higher-level sessions coordinate responsibility, evidence, review, and continuation.