Summary
The direction of CANCEL is inconsistent across the spec, the gRPC binding comments, and the Python message model.
Evidence
spec/04-messages.md lists CANCEL as Brain → Body.- The
CANCEL section says it is sent by the Brain to request cancellation of an in-flight tool call.
spec/05-transports.md includes CANCEL in both BodyMessage.type and BrainMessage.type comments.- The Python implementation includes
CancelMessage in both AnyBodyMessage and AnyBrainMessage.
Why it matters
Implementers need to know whether CANCEL is unidirectional or bidirectional. If Body → Brain CANCEL is allowed, its semantics should be defined separately from Brain → Body tool cancellation. If it is not allowed, the reference binding and Python model should not advertise or accept it as a Body message.
Possible fixes
- Make
CANCEL explicitly Brain → Body only and remove it from Body-side bindings/models.
- Or define bidirectional
CANCEL, including what Body → Brain cancellation means and how it differs from INTERRUPT.
- Add examples for whichever direction(s) remain valid.
Summary
The direction of
CANCELis inconsistent across the spec, the gRPC binding comments, and the Python message model.Evidence
spec/04-messages.mdlistsCANCELas Brain → Body.CANCELsection says it is sent by the Brain to request cancellation of an in-flight tool call.spec/05-transports.mdincludesCANCELin bothBodyMessage.typeandBrainMessage.typecomments.CancelMessagein bothAnyBodyMessageandAnyBrainMessage.Why it matters
Implementers need to know whether
CANCELis unidirectional or bidirectional. If Body → BrainCANCELis allowed, its semantics should be defined separately from Brain → Body tool cancellation. If it is not allowed, the reference binding and Python model should not advertise or accept it as a Body message.Possible fixes
CANCELexplicitly Brain → Body only and remove it from Body-side bindings/models.CANCEL, including what Body → Brain cancellation means and how it differs fromINTERRUPT.