Read-Only Personal AI for Cognitive Exhaust Analysis

waypoint_ai · Tech · 2026 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Personal AI observer systems and privacy-preserving reflection

Shimon wanted a personal AI system that could surface cross-source patterns in digital behavior without taking autonomous actions or contaminating the very behavioral data it analyzes.

Constraints:

• The system needed to combine multiple personal data sources that were not designed to interoperate.
• Write access was intentionally excluded because erroneous actions in relationships, career, or reputation contexts have unbounded downside.
• The source data had to remain uncontaminated by AI-generated writes so the observer could still analyze human behavior rather than human-AI feedback loops.
• Cross-source queries could be slow and token-heavy, especially when CRM/MCP searches and browser history entered the context.

Architecture

Fulan is a read-only personal observer built around three zones: source systems, a Claude analysis workspace, and a separate Obsidian output area. Claude skills launch Python scripts that gather data from read-only sources, call Anthropic's API with structured prompts, and write synthesized reflections for human review rather than sending messages or updating source systems.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  A["Read-only source zone"] --> B["Python data collection scripts"]
  B --> C["Claude analysis workspace"]
  B --> F["Anthropic API"]
  D["Clay MCP CRM search"] --> C
  E["Vivaldi SQLite browser history"] --> C
  C --> G["Obsidian review vault"]
  G --> H["Human reviewer"]

Components

Data flow

Six read-only personal data sources feed Python scripts launched from Claude skills. The scripts collect source data, pass it to Claude with specified prompts, and create structured markdown outputs. Claude performs cross-source analysis in the workspace, then deposits recommendations and reflections into a separate Obsidian vault where the user decides what to do.

Why this architecture

The architecture treats read-only access as a product boundary rather than a missing feature. Keeping writes out of source systems reduces catastrophic action risk and preserves clean observational data, while separating outputs gives the human a review gate before any real-world action.

Models used: Claude · Claude 4.6

Scale

• The system starts from six read-only data sources.
  “The starting point, six sources, read access only, no write permissions.”transcript, stated
• One cross-source query combines four data sources.
  “Four data sources, none of which were designed to talk to each other, combined into an insight you'd never get from any single tool.”transcript, stated
• Some queries are large enough that the speaker recommends clean sessions despite Claude 4.6's million-token context.
  “this takes up a lot of tokens in the context window, so you probably don't want to do this in a session that is not clean”transcript, stated

Alternatives considered (roads not taken)

Build a personal AI agent that writes or acts on the user's behalf

Rejected because: The system deliberately avoids write permissions because write errors in personal domains can be catastrophic.

Let Claude write directly back into the same source systems

Rejected because: Writes would pollute the behavioral exhaust and make later analysis unable to distinguish human patterns from AI-influenced ones.

Treat read-only observers as immature agents

Rejected because: The speaker argues observers and agents are distinct product categories with different risk/value profiles.

Patterns

privacy-preserving-processing (safety)

The system enforces read-only access and separates outputs from sources to reduce write-error, exfiltration, and cognitive-pollution risks.

human-in-the-loop-gate (governance)

The AI produces suggestions and reflections, but the user reviews them in a separate workspace before taking any action.

context-engineering (context)

The system curates multiple personal data sources into Claude sessions and manages context-window pressure by recommending clean sessions for large cross-source queries.

prompt-versioning (operations)

Structured prompts are treated as reusable infrastructure inside Claude skills and Python-driven reflection workflows.

Tradeoffs

Constrain the system to read-only observation instead of autonomous action.

Chose Read-only observer architecture over Agent that writes, sends, schedules, or edits source systems.

Rationale: The speaker values lower catastrophic risk and cleaner analysis over direct automation.

Persist synthesized outputs separately rather than modifying source tools.

Chose Separate Obsidian review vault over Writing reflections or tasks back into source systems.

Rationale: A separate output area preserves source integrity and keeps execution under human control.

Accept third-party model/API exposure for practical personal analysis.

Chose Claude/Anthropic API workflow over A fully local or fully isolated personal AI deployment.

Rationale: The system gains practical analytical capability but carries consciously accepted data-exposure risk.

Gotchas (what bit them)

Cross-source intelligence also creates a high-value privacy target.

Root cause: The same aggregation that creates insight can combine innocuous personal facts into sensitive profiles.

Resolution: The system reduces write/action channels but explicitly treats the remaining privacy risk as accepted rather than eliminated.

Read-only does not fully break the lethal-triquetra threat model.

Root cause: Shell access and external communication paths remain even if natural write-back channels are removed.

Resolution: The design lowers risk but does not claim fireproof security.

Cross-source queries can become slow and context-heavy.

Root cause: CRM/MCP search and broad browser/context data consume substantial runtime and context-window budget.

Resolution: Run heavy analysis in clean sessions and accept latency for reflective, non-real-time use cases.

Evaluation

The talk evaluates the system qualitatively through demos and use cases rather than a formal benchmark. The examples show whether cross-source synthesis can reveal intention-action gaps, reading-partner recommendations, and weekly reflection themes.

Metrics: Ability to combine sources no single tool can see · Whether recommendations remain suggestions rather than actions · Risk reduction from read-only access · Practical latency/token burden for cross-source queries

Outcomes

• The system generates weekly reflections assembled from digital exhaust rather than direct self-report.
• A cross-source reading-partner workflow maps contacts to articles without sending messages or scheduling anything.
• The read-only design supports analysis while keeping action decisions with the human.
• Security risk is reduced but not eliminated.

Personal prototype scale: six read-only sources, four-source cross-source demo, Claude/Anthropic API calls, Clay MCP CRM search, Vivaldi SQLite browser history, and Obsidian review outputs.