DSH Personal Agent Toolchain: Recall, Nudges & Cache

As a Personal Agent matures, the main question changes from whether it can call tools to whether it recalls the right memory, notices an installed capability, controls long-running cost, and detects an unexpected model-route change.

A DSH community member published a long-running workflow built from memory files, a commitment ledger, a watchdog, a phone dashboard, image generation, and document writing. The system was separated into four plugins and two skills. It is a useful architecture case study; the implementations are community projects, so their permissions, dependencies, and data paths still need review before installation.

Four independent paths

1. Memory recall

dsh-recall retrieves relevant memory before each turn and appends it near the current context rather than rewriting the system prompt. This can preserve a stable prefix while keeping retrieved material close to the active request.

Start retrieval in dryRun. Record matches, scores, and final injected length without changing the Session. After measuring false recall, enable injection gradually with per-turn item and token limits.

2. Capability nudges

dsh-capability-nudge matches the user message against a capability ledger and adds a short reminder only on a hit. A miss leaves the turn unchanged. It addresses the case where a capability is installed but the model does not consider it at the right moment.

A nudge should identify an available path, not approve a risky action for the user. Keep its text short and stable so it does not rewrite a large prompt prefix on every turn.

3. Cache auditing

dsh-cache-audit looks for files or prompt fragments that change every turn. Timestamps, random ordering, live counters, and ever-growing logs can invalidate KV Cache early when placed inside a stable prefix.

The audit should produce a list of change sources: which file changed, where it appears in the prompt, and whether the change has task value. Move high-frequency dynamic material toward the context tail before introducing a more elaborate cache layer.

4. Model-route verification

dsh-modeltrace performs scheduled model-fingerprint checks and can warn or block. For a persistent Personal Agent, this helps detect provider routing, model aliases, or upstream service changes.

Do not rely on one output characteristic as proof. Store provider, model ID, request time, important capabilities, and provider usage records together as an auditable call trace.

Do not install the complete stack at once

A safer build order is:

1. establish identity, boundaries, and approvals in a dedicated Profile and AGENTS.md;
2. add editable memory with confirmation for writes;
3. observe recall in dry-run without automatic injection;
4. add short capability nudges and measure hits and false triggers;
5. enable cache auditing and clean up dynamic prefixes;
6. add model verification, watchdogs, commitment tracking, and a remote dashboard last.

The dashboard belongs last because a remote entry point expands authentication, network, and lost-device risk. Stabilize the local workflow before adding mobile observation and low-risk controls.

An auditable event record

Each automatic action should retain at least:

This separates bad recall, a missing nudge, a changed model route, and a failed tool execution. A single undifferentiated activity log makes those failures harder to diagnose.

Start with the step-by-step DSH Personal Agent tutorial, then use Personal Agent memory design and the DeepSeek Personal Agent architecture guide for storage and permission boundaries.

References

• Community Personal DSH toolchain and plugin notes
• Community project index and source links
• DSH Personal Agent tutorial
• Personal Agent memory design