A second session exists only across a boundary one session cannot cross

outcome

Decide when work uses a second session, what a chain is then, and which messages between sessions are the exception.

context

An agent or a Workflow role returns its result into its parent's turn, runs on any provider's model through the plugin's lanes, and needs no address, message or record. A session is heavier: it holds a context of its own, re-reads it at every turn, and can be reached only by a message. Earlier practice ran most work as chains of sessions with a messaging network and built glue for it, much of it to work around a terminal and a delivery that waited for a turn to end. The person who approves this design ruled that, with agents and Workflows that mix providers, most work does not need that. A session started by another application on the same operating system is a native peer; a container and its host are not.

decision

A second session is started only for one of three boundaries: another operating system, another repository or permission profile, or a part large or long enough to need a context of its own. The sessions started for one piece of work form a chain, in which the top has no parent and every other session is a lead with exactly one parent. A chain has no roles beyond top and lead. Inside a chain a message is a brief down, a report up or a correction down. A message between two sessions of no common chain is allowed, rare and recorded, and it gives neither side a role.

rationale

• Hard to reverse because every project's guidance will teach when to start a session. Surprising without context because the plugin ships coordination while its own guidance tells sessions not to use it for most work. A real trade-off: a lead's own context and reach against a layer that re-reads its context at every turn, with a message as its only way back.

alternatives

• Port the earlier practice whole, with coordinators, stewards, single-use sessions, a roster, wait loops and forwarded queues. It answers terminal and queue problems that native messaging removes, and each layer re-reads large contexts.
• A record without a chain. It shows what was said but not who started whom, so nothing says where a lead reports or who owns what it left running.
• Free peer addressing through a roster. With no parent, nobody owns what a session was asked to do.

consequences

• Agents and Workflow roles never join a chain and are never recorded as sessions.
• A chain is shallow by design: the top and one level of leads. A deeper chain is recorded and shown with a notice, and nothing refuses it.
• A project's guidance names its own boundaries, and it does not carry a general rule to start sessions.
• A coordinator, a steward and a single-use session are practices of a top and of short leads, and they are not roles.

Verifier bindings

No verifier binding recorded.

Requirement drawing

• Declared verifying examples: no declared verifying example.
• Satisfying or referencing units: no recorded binding.
• Test or oracle bindings: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.