All projectsProject / Personal AI systems
Alfred → Sheldon
A personal AI assistant, built in stages.
I’m evolving a local-model prototype into an assistant that helps organize information, preserve useful context, and track commitments. The project brings together systems integration, troubleshooting, and a practical question: how can an assistant help without taking control away from the person using it?
Active development / Sheldon V2 foundation
01 / Alfred V1
Get the first
system working.
Alfred combined a Telegram interface, a Python message handler, and Ollama running the phi3 model on a dedicated Mac. The public notes document a previously working prototype with macOS Automator controls for starting, stopping, restarting, and checking the system.
I worked through model warm-up, startup order, duplicate bot processes, and Python environment issues. Those lessons became part of the operating documentation.
Model inference ran locally; Telegram remained an external communication service. Live operation was not tested for this case study.
02 / Sheldon V2
Make the context
useful and inspectable.
The current development foundation adds Python scan ranking, duplicate detection and suppression, source-linked commitment tracking, and inspectable JSON memory with correction records.
A local React dashboard presents the information through a Python backend built with the standard HTTP library. These are implemented foundations in active development; the broader assistant is still being built.
03 / Current foundation
Sources. Context. Human review.
Conceptual architecture overview
Read-only sourcesGmail and Google Calendar
Local snapshot readersAsana, Bee, and Apple Messages
Python processingRank items · Detect duplicates · Suppress noise
CommitmentsSource-linked records
MemoryInspectable JSON and corrections
Local dashboardReact interface / Python HTTP backend
Surface useful changes
Ranking and suppression help distinguish items worth reviewing from duplicates and recurring noise.
Keep the source attached
Commitment records retain source references so a follow-up can be checked against its original context.
Make memory correctable
JSON records and correction history keep stored context open to inspection and revision.
Be clear about access
Gmail and Calendar access is read-only. Asana, Bee, and Apple Messages are read through local snapshots rather than independent native connectors.
04 / Permission boundaries
Review before action.
The architecture separates reading, drafting, suggesting, and acting. The current foundation records approval decisions locally, but those records do not execute external actions. Permission to change external systems is not enabled in this implementation.
The design goal is to make recommendations reviewable and keep the person responsible for the decision.
05 / Engineering lessons
Build in observable steps.
Alfred taught me to check processes, dependencies, and startup behavior before blaming the model. Sheldon extends that approach to source provenance, memory corrections, and permission boundaries.
Skills: Python automation · Local-model integration · API and snapshot integration · React interfaces · Structured storage · Troubleshooting · Documentation
06 / Planned next steps
Extend the foundation.
Authenticated access across multiple devices, a voice interface, and supervised AV/DSP workflows are future work.
The AV direction includes assistance with signal-flow planning and designs for Symetrix Composer and Q-SYS Designer. These capabilities are planned, rather than completed features.
Public project notes
Follow the project’s evolution.
The public showcase repository preserves Alfred’s operating notes and documents the Sheldon architecture and roadmap. It is project documentation, rather than a packaged application ready to install.
Read the Alfred → Sheldon project notes 