Context
#862 already covers the prerequisite: marmot.agent-control.v1 has no reaction primitive at all, so an agent can't react to the user's message today. This issue is the follow-up UX spec for what to do with that primitive once it exists — a live processing-status indicator that updates as the agent moves through a turn, replacing the previous reaction each time rather than stacking multiple.
Traced against the actual Hermes hook surface (not hypothetical): agent/tool_executor.py and agent/agent_init.py already expose a tool_progress_callback(event_kind, tool_name, preview, args) with real, distinct event kinds firing through a turn — "_thinking" / "reasoning.available", "tool.started" (includes the tool name), and final response delivery. gateway/platforms/base.py defines on_processing_start / on_processing_complete, and Telegram/Discord/Slack adapters already implement a 2-stage version of this today: 👀 on receipt, swapped for ✅ or ❌ on completion. This issue asks to extend that existing convention with real intermediate stages, using the hook events above, rather than replacing it.
Proposed 4-stage set (not the emoji originally floated in chat — picked for clearer at-a-glance meaning)
- Received / queued → 👀 — kept as-is, matches the existing Telegram/Discord/Slack convention already in this codebase. No reason to change what's already working and familiar.
- Thinking (
_thinking / reasoning.available) → 💭 (thought balloon) — reads unambiguously as "in thought," clearer than a literal brain at reaction-size.
- Acting / tool call (
tool.started) → ⚙️ (gear) — a generic "system doing work" signal. Deliberately generic rather than per-tool icons (a search icon vs. a file icon vs. a network icon) since that would multiply the reaction vocabulary and isn't needed for the core "something is happening" signal — worth flagging as a possible future refinement, not part of this spec.
- Writing the reply → ✍️ (writing hand) — direct match for "composing a response now."
- Done → ✅ success / ❌ failure — unchanged from the existing convention.
Each new stage replaces the previous reaction rather than adding another one, so the message only ever shows one live status reaction at a time — this was explicit in the original ask and matters for not cluttering the message with a stack of stale reactions.
Dependency
Blocked on #862 landing first (no reaction primitive exists in the agent-control protocol yet, and the Python adapter has no reaction call to make). This issue is the UX/stage spec to implement once that primitive exists — not independently actionable today.
Context
#862 already covers the prerequisite:
marmot.agent-control.v1has no reaction primitive at all, so an agent can't react to the user's message today. This issue is the follow-up UX spec for what to do with that primitive once it exists — a live processing-status indicator that updates as the agent moves through a turn, replacing the previous reaction each time rather than stacking multiple.Traced against the actual Hermes hook surface (not hypothetical):
agent/tool_executor.pyandagent/agent_init.pyalready expose atool_progress_callback(event_kind, tool_name, preview, args)with real, distinct event kinds firing through a turn —"_thinking"/"reasoning.available","tool.started"(includes the tool name), and final response delivery.gateway/platforms/base.pydefineson_processing_start/on_processing_complete, and Telegram/Discord/Slack adapters already implement a 2-stage version of this today: 👀 on receipt, swapped for ✅ or ❌ on completion. This issue asks to extend that existing convention with real intermediate stages, using the hook events above, rather than replacing it.Proposed 4-stage set (not the emoji originally floated in chat — picked for clearer at-a-glance meaning)
_thinking/reasoning.available) → 💭 (thought balloon) — reads unambiguously as "in thought," clearer than a literal brain at reaction-size.tool.started) → ⚙️ (gear) — a generic "system doing work" signal. Deliberately generic rather than per-tool icons (a search icon vs. a file icon vs. a network icon) since that would multiply the reaction vocabulary and isn't needed for the core "something is happening" signal — worth flagging as a possible future refinement, not part of this spec.Each new stage replaces the previous reaction rather than adding another one, so the message only ever shows one live status reaction at a time — this was explicit in the original ask and matters for not cluttering the message with a stack of stale reactions.
Dependency
Blocked on #862 landing first (no reaction primitive exists in the agent-control protocol yet, and the Python adapter has no reaction call to make). This issue is the UX/stage spec to implement once that primitive exists — not independently actionable today.