Where should the application logic for smart glasses run?
Put each responsibility where the platform supports it and where its dependencies are available. The glasses may handle display and input while a phone manages state and service connections. A server may generate results. Some platforms also support meaningful logic directly on the glasses.
Assign an owner to each part of the state
Capture, requests, cancellation and rendering need clear boundaries. If the phone owns a task, the display should not invent a new task state during a reconnect. If the server returns a late result, the phone needs to know whether that request is still relevant before forwarding it.
Sketch those responsibilities before adding features. A simple architecture with explicit ownership is easier to debug than several devices each maintaining a slightly different version of the current screen and pending action.