Version skew at the persistent agent-host boundary

A client offering AHP 0.7.0 failed to communicate with a host accepting the 0.8.0 line, according to a VS Code issue classified as a probable bug and targeted to milestone 1.137.0 (source). This establishes one failed configuration and its disposition, not a general compatibility boundary between releases.

The failure matters because Microsoft’s Agent Host architecture moves session ownership into a dedicated process and permits multiple clients to connect. Its AHP description includes version and capability negotiation, synchronized snapshots, ordered actions, and reconnection (source). When clients and hosts can change independently, session persistence does not by itself establish interoperability.

Start with the supported combinations

Before changing either side, name the mixed-version window the deployment intends to support. Include pairings inside the window and immediately outside it. For each pairing, retain the client build, host build, offered and accepted protocol ranges, negotiated version, advertised and effective capabilities, session identifier, connection result, reconnect result, and user-visible error.

This record describes exact builds under selected conditions. It does not show that an entire release line interoperates. Classify each pairing as connected, rejected, or indeterminate, and attach the corresponding client and host evidence.

The reported 0.7.0-versus-0.8.0 mismatch shows why the protocol values belong beside the outcome (source). “Could not connect” is less useful than a record identifying both peers and their incompatible ranges. Correlated timestamps, build identifiers, capability exchange, session identity, and the terminal error can make the failure diagnosable. This evidence format is proposed here; the sources do not prescribe it.

Sensitive session content need not enter the record. Preserve only the negotiation and identity fields needed to distinguish a compatibility rejection from missing state or an unintended replacement session.

Exercise three release events

Create a disposable session with a known-compatible client and host. Give it enough recognizable state to determine whether a later connection returns to that session. Then exercise three independent release events:

• advance the client while holding the host fixed;
• advance the host while holding the client fixed;
• change both sides across the declared support boundary.

Where builds are available, compare previous, current, and candidate releases. Include one pairing expected to be incompatible. Its purpose is not to generalize the reported issue across versions, but to determine whether the deployment’s unsupported combination is rejected clearly.

For every event, answer three separate questions: Did the peers negotiate a protocol version or reject the connection? If they connected, which capabilities became effective? If a session already existed, did the client return to it rather than create a new one?

Microsoft documents negotiation, capabilities, snapshots, and reconnection as architectural features (source). It does not state that every release mixture will connect or recover identically. Separating these questions is therefore a proposed operating method, not an AHP guarantee.

Classify recovery precisely

A transport connection is not a complete result. A pair may connect with fewer effective capabilities. A client may reconnect but recover unexpected state. An incompatible client may fail correctly if the rejection is explicit and leaves the existing session distinguishable from any replacement.

After each interruption, assign one of four outcomes:

• the client resumed the same session with the same effective capabilities;
• the client resumed the same session with different capabilities;
• the client received an explicit incompatibility error;
• the interface appeared to recover by opening a different session.

These outcomes support different rollout choices even when the interface remains available. Inspect the client-facing message as well as the host log. A user connecting from a desktop, browser, or remote surface needs a bounded next action, such as selecting a compatible client or host release. That message is a proposed acceptance criterion; the sources do not establish current behavior.

Choose the disposition before rollout

The collected evidence can support several policies. A team might hold a host upgrade until supported clients are available, advance the host and reject older clients explicitly, or permit limited overlap only for pairings whose negotiated capabilities and recovery behavior have been observed. AHP documentation does not require any of these policies.

Record the permitted version envelope, the disposition outside it, and the evidence required to expand it. A failed connection can then be classified as expected policy enforcement or as a release defect. The persistent session and a particular client’s ability to use it remain separate claims.

Related engineering notes are available on the Super Genius Labs build page.