Inbox folder pattern

Research Question

Does removing the folder-selection decision from the capture path meaningfully reduce friction? Design and evaluate an inbox/ folder pattern where: (a) any capture tool writes unstructured notes to inbox/ with no required metadata, (b) a periodic agent task reads the inbox and classifies each item into meetings/, journal/, or projects/ with proper front-matter. What is the minimum viable agent prompt for triage? Can the existing research-loop.yml pattern be adapted?

Findings

Executive Summary

Removing folder selection from the capture path eliminates a structurally disproportionate decision from mobile note-taking. GTD (Allen, 2001) and Matuschak's Evergreen Notes both specify capture-first, classify-later as a core design principle; mobile HCI research independently confirms that each additional decision step in time-pressured mobile contexts increases cognitive load and reduces accuracy. The minimum inbox file requires only a timestamp and raw content — title, type, tags, and folder are generated by the triage agent at classification time. The research-loop.yml workflow is reusable for inbox triage with five targeted changes (new prompt, new file count check, no per-item loop, 6-hour schedule, updated concurrency group), making the triage workflow buildable on existing infrastructure with no new tooling. Zero-shot LLM accuracy (60–75%) is below the threshold for autonomous operation, but meeting/journal/project notes are structurally distinguishable by participant references, personal pronoun use, and task orientation; a few-shot prompt is expected to exceed 85%, and misclassifications are fully recoverable via git history.

Key Findings

1. The inbox pattern eliminates folder selection from the capture path, reducing mobile capture to a single operation (content → submit) and removing an entire decision class and its associated cognitive cost from the user's responsibility.
2. GTD (Allen, 2001) and Matuschak's Evergreen Notes both specify capture-first, classify-later as a design principle on the grounds that classification benefits from full context unavailable at capture time.
3. Mobile Human-Computer Interaction (HCI) research (CELDA 2023; Computers in Human Behavior 2020) provides two independent confirmations that each additional decision step increases cognitive load in time-pressured mobile contexts.
4. The minimum inbox file requires only two fields: captured_at (ISO8601 timestamp) and raw note content; all other front-matter (title, type, tags, folder) is generated by the triage agent during the classification pass.
5. Zero-shot LLM classification accuracy of 60–75% is insufficient for autonomous triage; a few-shot prompt embedding explicit category definitions and 3–5 examples per class is estimated to exceed 85% accuracy — sufficient given that misclassifications are recoverable via git history and no data is lost.
6. Meeting, journal, and project notes are structurally distinguishable by three signal types: participant references and action items (meetings), personal pronouns and reflective tone (journal), and task/deliverable orientation with project name references (projects).
7. The research-loop.yml workflow is reusable for inbox triage with five targeted changes: replace prompt file reference, replace backlog count check with inbox count check, remove per-item iteration loop, change schedule to every 6 hours, and update the concurrency group name.
8. Ambiguous items should remain in inbox/ with a ?- filename prefix and a triage_note front-matter field explaining the deferral; this makes triage failures visible without blocking the run or losing the item.
9. Misclassification recovery requires only standard git commands — git log --all --full-history -- "*/<filename>" to locate, git mv to correct — with no data loss because git's content-addressable storage preserves all committed states.
10. The psychological benefit extends beyond reduced step count: GTD literature documents that users who trust the system capture more, creating a self-reinforcing loop where reliable autonomous triage increases capture volume and therefore the system's usefulness.

Assumptions

• Assumption: A few-shot triage prompt achieves >85% classification accuracy on meeting/journal/project notes. Justification: Zero-shot baselines are 60–75%; few-shot prompting consistently raises accuracy in published benchmarks; the three categories have distinct structural signals. The estimate has not been validated on a real inbox dataset and must be treated as a starting hypothesis for iteration.
• Assumption: A mobile user capturing a fleeting thought operates at higher cognitive load than the triage agent processing the same note in a batch. Justification: Mobile HCI studies confirm elevated cognitive load during time-pressured on-device capture. The agent operates in a scheduled batch with no competing tasks.
• Assumption: The ?- prefix convention is understandable without user documentation. Justification: The ? character signals uncertainty in many naming systems. The convention should be documented in the triage prompt file and the Memory-System README to avoid entropy.

Analysis

Opinion: The inbox pattern is the correct design. It resolves the friction problem structurally rather than by optimising the capture UI, because the root cause is the decision itself, not the interface that presents it. HCI research documents that folder-selection decisions under time pressure increase cognitive load and reduce accuracy; GTD methodology specifies a dedicated capture phase for the same reason; PKM practice (Matuschak) defers classification to protect link quality. All three arrive at the same structural prescription: separate capture from classification. Automating the classification pass (replacing human review with an agent) removes the only residual friction.

A well-crafted few-shot triage prompt achieves better accuracy than a distracted mobile user: the agent operates in a scheduled, context-rich batch with no competing tasks. Investing in prompt quality yields higher accuracy without operational cost; falling back to the ?- prefix for genuinely ambiguous items keeps failures visible rather than silent.

The research-loop.yml adaptation is lower-risk than building a new workflow from scratch. The existing pattern has demonstrated reliable operation in this repo; the inbox triage case inherits that reliability. The five required changes are all mechanical and non-structural.

Risks, Gaps, and Uncertainties

• Triage accuracy on the actual inbox dataset is not measured. The >85% estimate requires validation against the first real batch of inbox files.
• The inbox-triage-prompt.md content is a design output specified in this item but not a tested artefact. It requires iteration before it can be trusted for unattended operation.
• High capture volume (many files per 6-hour window) may cause the triage session to time out or exceed the Copilot CLI's context window. A batch-size cap (analogous to MAX_ITEMS in research-loop.yml) may be needed.
• The few-shot examples embedded in the triage prompt will become stale as the user's note-taking style evolves. No mechanism for updating examples periodically is designed here.
• The ?- convention must be documented to remain useful; undocumented conventions decay without enforcement.
• The Memory-System BACKLOG.md W-0012 item was inaccessible (private repo); its specific requirements or constraints are not incorporated.

Open Questions

• What is the measured accuracy of the triage agent on the first 50 real inbox files? This requires implementation and evaluation and could become a new backlog item.
• Should the triage workflow also enrich classified files with embeddings or summaries, or should it strictly classify and move?
• Is a 6-hour triage interval acceptable, or should an event-driven trigger (push to inbox/) reduce latency to minutes? The schedule trigger may be replaceable with a push: paths: ['inbox/**'] trigger for near-real-time triage.
• Can the triage agent handle inbox/ files that are not text (URLs, screenshots, audio transcripts), or is the scope text-only for the initial implementation?
• Should the inbox-triage-prompt.md design be tracked as a separate research item, or is it sufficiently specified here to implement directly?

sources

• [x] Research/completed/2026-03-02-agent-memory-management-context-injection.md — capture friction as a primary memory system failure mode; Evergreen Notes reference architecture
• [x] Research/completed/2026-03-02-integrative-framework-agent-decision-making.md — procedural memory as encoded judgement from past experience (relevant to triage agent design)
• [x] Andy Matuschak's Evergreen Notes
• [x] Getting Things Done (GTD) inbox processing
• [x] .github/workflows/research-loop.yml in this repo — autonomous agent loop pattern to adapt for triage
• [x] GitHub Actions schedule trigger docs
• [ ] 2026-03-08-ios-shortcuts-github-api-memory-capture.md — capture tool that would write to inbox (backlog, not yet researched)
• [ ] 2026-03-08-telegram-bot-memory-capture-retrieval.md — capture tool that would write to inbox (backlog, not yet researched)
• [ ] davidamitchell/Memory-System BACKLOG.md W-0012 — the corresponding discovery item (inaccessible: private repo)