Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Desire Path

Desire Path (dp) captures agent tool calls and turns repeated failures into patterns you can query. It is for developers maintaining agent instructions, tool names, and integrations. The CLI stores data in a local SQLite database; source plugins interpret each agent’s event format, and hooks connect capture to the agent.

A desire path is a trail worn into grass where people choose to walk. Here, a mistaken tool name is evidence of the interface an agent expected to find. A repeated failure can suggest a better tool name, a missing feature, or an instruction worth fixing.

From failure to a fix

  1. Ingest a call through a source plugin. Failed calls also become desires.
  2. Query dp paths to find repeated names and dp inspect for the details.
  3. Use dp similar to compare a mistaken name with known tools.
  4. Record a mapping with dp alias, then improve instructions or configure pave if active interception is appropriate.

An alias alone stores a mapping; it does not automatically reroute every call. The first-success example demonstrates capture and query without installing any hooks.

Capabilities and boundaries

capabilitywhat it does
PatternsRank repeated failures and inspect their error messages
SuggestionsCompare names with known tools using string similarity
AliasesStore intended tool mappings and command correction rules
Source pluginsNormalize calls from Claude Code, Codex, Cursor, and Kiro
ExportsWrite failure or invocation records for offline analysis
SignpostingOffer search guidance through optional agent hooks

Signposting observes weak searches and can offer a stack tool command. Its evaluation contract, limitations, and measurements are in the signposting plan and evaluation chapters. It is separate from basic capture.

Where to go next