Office Hours XII: Building Paul's Second Brain — the Full Project-Management System, Live

Step 1, VISIBILITY: adopt a project tracker (Linear demoed - GitHub-linked issues, its own API key so agents update it without the app being open, an MCP server). The justification is the cost problem itself: with heavy agent usage 'we really don't know if the output... is a net positive output happening or not' - a tracker makes agent work measurable.

Step 2, CONSOLIDATION: upgrade to an open-source all-in-one workspace (as-heard 'Macro', ~4,000 stars - name unverified): 'email plus channels like Slack and calls, notion, linear, notion calendar, agents everything combined in one' - and 'it's open source so you can just go ahead and download this entire code base.' Step 3, THE CONNECTIVE AGENT: a personal Hermes-style agent with documentation, emails, and proprietary intel attached - 'have all of these connected to one of your agent' so 'there is shared intelligence there is shared memory everything.' Step 4, SELF-HOSTING: a Hostinger VM running both workspace and agent under a custom domain (his own: a workspace subdomain with the tool's branding stripped) - co-location is what gives 'much better context on your entire project.'

The scale note: if the corpus is terabytes, size the VM accordingly (10-15TB named) - the POINT is that the knowledge lives permanently on the VM regardless of which PM tool sits on top later. And after Paul pushes back on lock-in: the incremental start - one file or the recent chats first, learn how it behaves, then expand.

The funnel: 'create a very simple repository call it project documentation or project specs,' push all existing work into it, connect that repo to the agent, then instruct the agent to dump the folder into the workspace. GitHub is the transport BECAUSE every agent already speaks it.

For the scattered-source problem, the pre-step: open a fresh Claude Code session with the prompt pattern 'I want to migrate all my work from the chats, my folder, my Google Drive, everything to GitHub - give me a plan'; explicitly tag the folders in scope; enable bypass-permissions so it can traverse the machine; switch to Opus for the judgment calls; verify GitHub is OAuth-connected first. Plan, then run. Cross-wiring two repos or two agent instances later: GitHub Actions (mind the free-tier limits) or the GitHub CLI.

The friction: agent harnesses are vendor-locked - Codex runs happily inside Hermes, but Claude 'forces' the Anthropic API with separate billing. The fix he names (as-heard 'Deep Seek harness' - NOT the DeepSeek lab; 'it just came out'): a lightweight, plugin-style harness - 'it doesn't live on your computer... not like a big heavy application' - that accepts any API key including OpenRouter, or an existing Claude/OpenAI subscription as pass-through. Chain: subscription -> harness -> agent, output landing in the workspace. The honesty clause arrives at [0:44]: the subscription trick holds only when subscription and harness/VM are CO-LOCATED on one machine. Raw API through it is still raw API pricing. He promises a how-to doc/GitHub upload for the routing specifics.

The clarification, verbatim: the all-in-one workspace 'is not a memory layer at all.' The workspace is the VISUAL hub - projects, docs, email, calendar, the place humans look. Memory layers (Praful's seven-layer memory system, and an as-heard 'Bell Lab' alternative that reportedly destabilizes on a VPS) are persistence architecture that plugs into the AGENT. Same agent, two different attachments, different failure modes. Practical notes along the way: the workspace installs fine under Docker - 'here's the github repository install this tool on your brain' addressed to Hermes; the seven-layer memory repo got shared as a link live rather than explained.

The concept: restructure sites so agents navigate them EFFICIENTLY - SEO's successor logic (the analogy to GEO is explicit), where a site exposes its functions to agents rather than forcing them through human click-paths. Cody layers a personalization idea he calls 'GraphLM' (as-heard): attention weights learned from ~30 days of a user's actual workflow, keeping trodden paths prominent while unused ones fade into an app-drawer that stays manually reachable - the phone home-screen pattern applied to the web. Harshit's response: promising, wants hands-on before judgment, plans to try it on his own site and report next session. His staging advice when Cody aims it at dashboards: prove it on a website first, where conversion lift is measurable - YC-backed teams have struggled starting from dashboard complexity.

Cody's product (as-heard 'VDX'): a floating voice bubble - the Messenger-bubble pattern - that drives ANY Android app through the OS accessibility layer, the same mechanism Talkback uses. No screenshots-in-a-loop (that's where competitors lose latency: 'it's calling the node'), no per-app APIs ('there's no API we are doing MCP into every app'), ~82 apps connected, fully on-device. Overlay-blocking apps (games) are the boundary - the bubble disables there. Status per Cody: feature-complete; the remaining work is benchmarking, market feedback, and licensing/accessibility certification for device scaling.

The principle: in therapeutic niches trust IS the product, so authentic face-to-camera UGC-style video outconverts synthetic likenesses - the AI tools stay in the toolkit for volume, not for the face. The landing-page idea stack: a calm AI voice agent greeting plus background music 'played right at a certain frequency'; a voice CLONE of the practitioner acceptable for the landing preview even where a face clone isn't.

The live site review's punch list: a visual 'storyboard' - consistent palette and uniform button styling ('not a full rebuild, just a visual revamp'); real imagery over stock; testimonials; one prominent consultation CTA; booking moved from Jane to Cal.com for integration reach; analytics via PostHog (as-heard 'postdoc', covered in a prior week); and volume distribution - vertical 15-20 second shorts generated fast (as-heard 'Seed Dance 2.5') plus paid ads.

Cody's living-dashboard idea: shadcn/ui components that reorganize by usage - prominent when used, app-drawered when not. Harshit's two-part guidance: strategically, prove the adaptive concept where the signal is cleanest (website personalization -> measurable conversion lift) before dashboards, where YC-backed attempts have stalled; theatrically, for judges, demo ON-THE-FLY GENERATION - type a natural-language analytics request ('show me newsletter signups by week') and watch the agent instantiate the missing shadcn component live from existing primitives.