Jonas Notes

Pathfinder - Curiosity Stack Implementation

5 min read

Pathfinder - Curiosity Stack Implementation

Purpose

This note moves the earlier curiosity-agent design from concept into implementation artifacts.

The goal is to make the system specifiable and runnable rather than leaving it as a brainstorm.

Primary corpus:

  • /home/claw/notes

Secondary corpus:

  • /home/claw/work-vaults/shopee-engineering-vault

Publishing surface:

  • /home/claw/notes-site/content/AI/Agents/

Important constraint:

  • the work vault is read/analyze only and is never mutated

What was created

A concrete implementation bundle now exists in:

  • /home/claw/.openclaw/workspace/curiosity-stack/

It contains three layers:

1. Shared state structure

Under state/:

  • dual-corpus-rules.yaml
  • interest-map.template.json
  • open-loops.template.json
  • candidate-backlog.template.json
  • recently-explored.template.json
  • frontier-inbox.template.json
  • state-index.md

These files define the durable memory model for the system:

  • what Jonas appears to care about
  • what open loops remain unresolved
  • what candidate topics are waiting to be surfaced
  • what has already been explored recently
  • what new frontier signals have been collected

2. Agent contracts / prompts

Under contracts/:

  • notes-distiller.md
  • frontier-scout.md
  • curiosity-ranker.md
  • topic-composer.md

These are the concrete role contracts for the four agents. Each one now has:

  • a role
  • objective
  • inputs
  • hard rules
  • output schema
  • heuristics
  • quality bar

This is the missing layer that turns the system from “some useful agents” into a real pipeline.

3. Flow specifications

Under flows/:

  • on-demand-recommendation.yaml
  • scheduled-background.yaml
  • implementation-notes.md

These define the orchestration behavior for:

  • interactive recommendation requests
  • quiet background maintenance
  • score thresholds and notification gating

Dual-corpus policy

The key implementation rule is:

personal vault is canonical; work vault is contextual and read-only

This is now encoded explicitly in dual-corpus-rules.yaml.

Operational interpretation

Personal vault

Use for:

  • interest modeling
  • identity and preference grounding
  • recommendation justification
  • writable note outputs
  • published summaries

Work vault

Use for:

  • transformed abstractions
  • pattern recognition
  • technical vocabulary alignment
  • generalized systems questions

Do not use it for:

  • verbatim publishing
  • recommendation payloads containing internal/raw material
  • any file mutation

Weighting policy

Candidate generation is intentionally biased toward the personal vault:

  • primary corpus weight: 0.75
  • secondary corpus weight: 0.25

That means work context can sharpen or boost a topic, but should not dominate the system.

The four agents, concretely

1. Notes Distiller

Purpose:

  • mine the personal vault for recurring themes, unresolved questions, and revivable threads

Writes/proposes:

  • interest-map
  • open-loops

Main anti-slop behavior:

  • prefer cross-note patterns over single-note summaries
  • prefer durable themes over generic tags
  • convert any work-vault influence into generalized abstractions

2. Frontier Scout

Purpose:

  • look outward for technical developments adjacent to Jonas’s actual curiosity graph

Writes/proposes:

  • frontier-inbox

Main anti-slop behavior:

  • every signal must connect to an existing interest or open loop
  • prefer pattern shifts, primitives, architecture changes, and disagreements over hype/news

3. Curiosity Ranker

Purpose:

  • score, deduplicate, and diversify candidates so only a few strong topics survive

Writes/proposes:

  • ranked candidate-backlog

Current scoring dimensions:

  • relevance
  • novelty
  • depth
  • adjacency
  • experimentability
  • timeliness

Main anti-slop behavior:

  • penalize repetition
  • reject shallow or sensitive items
  • preserve diversity across practical / conceptual / speculative outputs

4. Topic Composer

Purpose:

  • convert ranked candidates into user-facing recommendations

Delivery modes:

  • topic-of-the-day
  • boredom-queue
  • frontier-scan

Main anti-slop behavior:

  • default to one strong recommendation
  • only expand into a queue when it improves decision quality
  • keep chat concise and note expansion optional

On-demand flow

Defined in:

  • /home/claw/.openclaw/workspace/curiosity-stack/flows/on-demand-recommendation.yaml

This is the flow for prompts like:

  • “what should I focus on?”
  • “give me a rabbit hole”
  • “what am I not seeing?”
  • “give me something practical”

Behavior

  1. Load current state
  2. Check whether backlog freshness is sufficient
  3. If stale or thin, run a lightweight refresh
  4. Classify user intent
  5. Select one high-conviction item or a diversified 3-pack
  6. Compose the final recommendation
  7. Append result to recency memory

This makes the system responsive without requiring a full background run every time.

Scheduled/background flow

Defined in:

  • /home/claw/.openclaw/workspace/curiosity-stack/flows/scheduled-background.yaml
  • Notes Distiller: 2–3x per week
  • Frontier Scout: 2x per week
  • Curiosity Ranker: after each upstream refresh
  • Topic Composer: only when a topic clears threshold or when explicitly requested

Important decision

This system is not designed to force a daily topic.

Instead:

  • notify only when quality clears threshold
  • skip weak days
  • prefer 3–5 strong outputs per week over daily sludge

Current thresholds:

  • topic of the day min score: 0.78
  • boredom queue min score: 0.68
  • suppress same-theme repeat within: 5 days

Why this is now implementation-ready

Before this pass, the curiosity stack existed mainly as role descriptions.

After this pass, the system now has:

  • explicit shared state
  • explicit corpus rules
  • explicit agent contracts
  • explicit orchestration flows
  • explicit recommendation gating

That means the remaining work is mostly execution wiring:

  • run the contracts with a real orchestrator or script
  • persist concrete state files from the templates
  • optionally add source scanning helpers or ACP/OpenClaw job wrappers

In other words:

the architecture step is done; what remains is operationalization

Suggested next implementation step

The cleanest next step would be a small runner that does:

scan personal-note deltas
-> run Notes Distiller
-> sample frontier inputs
-> run Frontier Scout
-> run Curiosity Ranker
-> persist backlog
-> call Topic Composer when user asks or when threshold passes

That could live as:

  • an OpenClaw orchestration script
  • a lightweight Node/Python runner
  • or a future ACP-managed job chain

What remains

Design-wise, very little remains.

Operationally, the remaining items are:

  1. instantiate the template files into live state files
  2. decide the concrete execution runner
  3. optionally define source lists for Frontier Scout inputs
  4. optionally add logging / telemetry for recommendation quality over time

None of those require rethinking the system shape.

File map

Workspace implementation bundle

  • /home/claw/.openclaw/workspace/curiosity-stack/README.md
  • /home/claw/.openclaw/workspace/curiosity-stack/state/dual-corpus-rules.yaml
  • /home/claw/.openclaw/workspace/curiosity-stack/state/interest-map.template.json
  • /home/claw/.openclaw/workspace/curiosity-stack/state/open-loops.template.json
  • /home/claw/.openclaw/workspace/curiosity-stack/state/candidate-backlog.template.json
  • /home/claw/.openclaw/workspace/curiosity-stack/state/recently-explored.template.json
  • /home/claw/.openclaw/workspace/curiosity-stack/state/frontier-inbox.template.json
  • /home/claw/.openclaw/workspace/curiosity-stack/contracts/notes-distiller.md
  • /home/claw/.openclaw/workspace/curiosity-stack/contracts/frontier-scout.md
  • /home/claw/.openclaw/workspace/curiosity-stack/contracts/curiosity-ranker.md
  • /home/claw/.openclaw/workspace/curiosity-stack/contracts/topic-composer.md
  • /home/claw/.openclaw/workspace/curiosity-stack/flows/on-demand-recommendation.yaml
  • /home/claw/.openclaw/workspace/curiosity-stack/flows/scheduled-background.yaml

Main note

  • /home/claw/notes/AI/Agents/Pathfinder - Curiosity Stack Implementation.md

Published mirror

  • /home/claw/notes-site/content/AI/Agents/Pathfinder - Curiosity Stack Implementation.md

One-paragraph summary

The curiosity / second-brain stack is now specified as a concrete implementation bundle: shared state structures, dual-corpus rules, four executable agent contracts, and both on-demand and scheduled orchestration flows. The system is intentionally biased toward Jonas’s personal notes, treats the Shopee work vault as read-only contextual input, and is designed to surface a small number of high-conviction recommendations instead of becoming a trend feed.

Backlinks