DSH Desktop Pet State: Tool Calls and Ambient Feedback

As Agent tasks become longer, users need more than another “working” message. They need persistent feedback that does not occupy the main workspace. A community desktop-pet plugin demonstrates one approach: observe structured DeepSeek Harness markers and react when commands, edits, search, tests, reviews, deployments, or debugging begin.

The result is an ambient interface. A glance at the screen corner confirms that the system is active without requiring the terminal or event log to remain open.

Structured events, not page-text guesses

A reliable companion should consume Tool Call lifecycle, Session runtime, terminal status, and completion events. Those signals can be reduced to a small state model: idle, working, completed, failed, and waiting for the user.

The community implementation can vary poses by tool category while remaining quiet during work. That is more suitable for a development environment than continually generating character dialogue: state stays visible while attention stays on code and deliverables.

Debouncing state transitions

One Agent turn may read files, search, edit, and test in rapid succession. Switching artwork for every event creates flicker. The state layer should enter working on the first tool, remain there across consecutive tools, wait briefly after the last result, and return to idle only when no new job appears. Failure and user-confirmation states should take priority.

Preloading assets and masking image transitions also matters. Stability contributes more to a low-interruption interface than the total number of animations.

Keep the companion outside execution

Feedback must observe DSH without deciding whether a Tool Call runs. Sessions, terminals, and tools should continue when the pet script crashes, an asset is missing, or the plugin is disabled.

Maintain three boundaries: subscribe without rewriting task state; store animation and progression separately from Session records; uninstall without modifying built-in DSH packages or leaving required boot hooks.

The community plugin uses front-end injection and read-only resource routing. This reduces coupling, but every DSH update still requires checking structured markers and plugin contracts.

A general Agent-status pattern

The same model can drive menu-bar icons, notifications, physical lights, or remote dashboards. The character is optional. The durable design compresses complex execution into a few recognizable stages and allows users to open the underlying evidence.

A working state can link to the active Tool Call, a failure state to its log, and a waiting state to the confirmation message. Ambient feedback attracts attention; the DSH interface provides the explanation.

References

• Community desktop pet v2.4.0 and work-state reactions
• Desktop support, plugin contracts, and privacy settings
• Early work-state and animation design

FAQ

Does the pet need complete chat content?

Basic work-state feedback only needs structured runtime events. Keyword-aware features that inspect chat content should be separate and disabled by default.

Why can it remain in a working pose after the answer ends?

A Subagent, terminal process, or Tool Call may still be active, or the plugin may not have recognized the completion event.

Can this state prove that a task succeeded?

No. It reflects runtime events. Tests, changed artifacts, and acceptance criteria still establish success.