
Remote Agent Hosts Need Correlated Multi-Stream Contracts, Not Arrival-Order Assumptions
Once remote agent execution splits control events, tool calls, and results across independent streams, cross-stream reordering becomes a normal condition. Reliable finality must come from execution IDs, invocation IDs, sequence evidence, acknowledgements, and drain watermarks rather than arrival order or an outer completed token.
When agent execution moves behind a remote host boundary, the tempting shortcut is to treat an RPC-level completed signal as safe completion. The harder engineering reality is the opposite: once control events, tool subscriptions, and tool results use independent streams, reordering is not an anomaly; it is part of the contract.
Central judgment
A remote Agent Host should treat cross-stream reordering as a first-class condition. Clients must reconstruct safe finality from stable identifiers, monotonic sequence evidence, acknowledgements, and closure watermarks, while keeping transport success, execution lifecycle completion, and business success as separate dimensions.
This article consumes only the Q-20260808-03 Research Object. Production did not reopen signals or the Reading Result for new analysis.
Source
The sole analytical input is Research Object — Correlated Multi-Stream Agent Host Contract. The Reading Result remains only the evidence-provenance path declared by that object.
Observation
The Research Object describes a versioned remote-host boundary that separates session ownership, execution, waits, cancellation, termination, tool callbacks, notifications, and typed content results. Different traffic classes may use independent HTTP/2 streams so that high-volume tool payloads do not block every control event.
The tradeoff is loss of one global arrival order. A close event arriving first does not prove that every lower-numbered tool callback has already arrived. An execution lifecycle reaching a terminal state does not prove that its nested result lacks error_text. A transport-successful RPC does not prove business acceptance.
Comparison
| Signal | What it establishes | What it does not establish | Additional evidence needed |
|---|---|---|---|
| RPC transport success | This transport exchange succeeded | Business work is correct | Typed execution result |
ExecutionCompleted | Execution lifecycle reached terminal state | Semantic success | Nested error/result state |
| Close / CellClosed | A close event was observed | All callbacks are drained | Sequence watermark |
| Local cancel action | Local code requested cancellation | Remote wait is retired | Remote acknowledgement |
| FCoP task state | Shared work/behavior semantics | gRPC stream order or connection liveness | Runtime transport evidence |
The table is a Research Center synthesis from the Research Object. The FCoP row is an explicit boundary statement, not a claim that FCoP is a transport protocol.
Discussion
Stream separation buys concurrency by moving correctness into correlation. An execution ID ties together one execution, an invocation ID ties together a tool call, sequence numbers reveal missing earlier events, and a final watermark defines how far a client must drain before it can safely retire local state.
Cancellation needs the same discipline. Dropping a future or closing a UI action means only that the local side stopped waiting. It does not establish that the remote host retired the old wait. An acknowledgement-bearing transition prevents late results from an earlier wait from contaminating a later execution.
The Research Object also preserves an important limitation: a package-level v1 namespace is durable naming, not runtime feature negotiation. Authentication, authorization, retry/idempotency rules, and mixed-version capability discovery remain separate requirements for production-grade remote execution.
Engineering impact
If CodeFlowMu externalizes worker execution over RPC, high-volume tool payload traffic should be separable from control/event traffic while execution, invocation, wait, and cancellation receive stable IDs, sequence evidence, closure watermarks, and durable effect receipts.
WorkOrder identity should sit above a provider or host session lease. Losing a transport session may terminate a remote execution context, but it must not erase long-lived task truth. Recovery should continue from durable WorkOrder state, accepted evidence, and unresolved decisions.
FCoP should remain the shared behavioral/work protocol surface rather than absorbing gRPC ordering, connection liveness, or transport retry semantics.
Boundaries and counter-evidence
The evidence is mainly a protocol/bindings change and does not demonstrate real-load concurrency performance or backpressure behavior. Stream-loss-as-session-lease semantics do not provide transparent reconnect by themselves. Authentication, feature negotiation, idempotency for mutating RPCs, and end-to-end concurrency guarantees remain unestablished.
The claim is therefore about making remote execution semantics reason-able and auditable, not proof that the protocol is already production-complete.
Future work
Next work should identify which CodeFlowMu events need monotonic sequence numbers or closure watermarks, define a reconnect model that preserves WorkOrder continuity, add idempotency keys and durable receipts for mutating RPCs, and layer feature negotiation without coupling FCoP work semantics to transport details.
Visualization note
The diagram shows three independent streams converging on a correlation layer, then using sequence evidence, acknowledgement, and a drain watermark to produce safe finality. It is a Research Center synthesis and does not imply an unmeasured performance gain.
Evidence and references
- Research Object — Correlated Multi-Stream Agent Host Contract: sole analytical input for Production.
- Reading Result — Code-mode gRPC Host Protocol: evidence-provenance path declared by the Research Object; Production did not perform new research from it.