Summary

Cole Medin walks through the architecture of a personal 'second brain' he has run for three months — a memory layer of markdown files, skills for capabilities, direct API integrations with deliberately narrow permissions, and a scheduled 'heartbeat' that acts proactively — built on Claude Code and the Claude Agent SDK with an Obsidian vault as the store. The argument is structured around a security case rather than a feature list: he opens by arguing why one should build this rather than run an existing off-the-shelf equivalent, and the permissions design follows from that. He does not release his own code, offering instead a requirements template and a skill that generates a phased build plan. Note the posting date: this video is from 1 April 2026, roughly six months older than the rest of this batch, so its product and model references are correspondingly dated. It carries promotion for a paid community workshop.

• The central framework is what he calls the 'lethal trifecta' — three conditions that together make an agent seriously exposed to prompt injection. Private data access: the agent can reach email, calendar or similar. Untrusted content: any input can arrive that did not come from the user, such as an incoming email or web page, which may carry malicious instructions. An exfiltration vector: some way to send data out, such as sending a message or posting to an API endpoint.
• His argument is that all three must be present for the serious risk to exist, and that removing any one of them reduces it substantially — but that a personal assistant of this kind has all three by default, and that it is 'really hard to make a useful second brain without being exposed' to them. The conclusion he draws is not to avoid the exposure but to minimise each pillar deliberately, which is a more honest position than claiming the problem away.
• This is presented as a general framework for agents rather than a point about this project, and it is the most reusable thing in the entry. He does not attribute the trifecta to an originator.
• His criticism of the off-the-shelf alternative is about comprehensibility, not just code quality: it is 'a massive code base that you don't understand', hard to adjust, and gives an agent a great deal of control without the user having a clear picture of what control was granted. He credits its maintainers with substantial recent work on prompt injection and calls the application beautifully crafted, while still declining to run it — a distinction worth preserving rather than flattening into a dismissal.
• His resolution is to take inspiration without taking the dependency: he pointed his coding agent at the open-source repository and had it study specific mechanisms — the memory layer and the proactive heartbeat — then implement its own versions. He describes this as standing on the shoulders of giants while retaining control of permissions.
• The permissions design is zero-trust and asymmetric in a way worth recording concretely. Read-only on Slack with no ability to post. Able to create Gmail drafts but not to send email. Able to manage tasks in certain projects only. Able to report calendar events but not manage the calendar. His stated approach is to start read-only and add capability deliberately.
• The memory layer is three markdown files — a personality file, a user file, and a memory file of key decisions — loaded into context automatically at session start via a hook. He took this structure directly from the open-source project he declines to run, noting there is no security issue with that part of it.
• Memory persistence works by promotion rather than accumulation. Every conversation is appended to a long raw daily log, via a pre-compact hook and an equivalent at session end. Once a day a scheduled job using the Agent SDK reads that log and promotes what is worth keeping — key decisions, lessons learned, important facts — into the concise memory file that is always in context. He calls this the part that lets the system evolve.
• Because promotion is lossy by design, the full daily logs are separately indexed into a SQLite database so the agent can search back for detail that was never important enough to promote. He notes Postgres would do equally well.
• He claims capabilities need only Claude Code plus skills, and states he uses no MCP servers at all and no other applications — everything is skills. This is his architectural preference, presented as following the general advice to prefer simple composable patterns.
• A compounding effect he describes: the skills are generic on their own, and it is the memory layer that makes their output specific to him — a script-writing skill produces something generic unless it can read how he has written similar things before.
• He reports building new integrations by having the agent copy the pattern of existing ones, referencing its own memory of how it built the previous ones, and says his chat interface was written so it could be duplicated for another platform. This is an unverified claim about ease, from the author of the code.
• The 'heartbeat' is the proactive component and the one he says saves the most time. A deterministic step gathers current context through the APIs, then passes it with a preconfigured prompt into Claude Code via the Agent SDK — so the agent is invoked programmatically rather than prompted — which reasons about what to do, acts, and then notifies him in Slack where he can reply in-thread to continue.
• He reports the system saves 'at least a dozen hours of work' and says he is not exaggerating for the video, grounding the claim in having run a similar business for eighteen months beforehand. It is a self-reported figure with no measurement behind it. He is clear the purpose is reallocating capacity to higher-leverage work rather than working less.
• The deliverable he offers is deliberately not code: a requirements document to fill in, and a skill that turns it into a phased build plan. His reasoning is that giving away the codebase would defeat the purpose and produce 'just another' of the thing he criticised. The template asks for a proactivity level — from observer, read-only, through to a partner acting autonomously including sending email — and he states his own is the middle setting, advisor.
• He advises against having a coding agent build the whole system in one attempt, saying it will not work and makes it hard to stay in control of what is being built, and recommends building phase by phase starting with the memory foundation.

Why it matters

The lethal trifecta is the part of this entry that belongs in the Handbook regardless of what happens to the tools involved. It converts a vague anxiety about agent security into three conditions that can be checked against any deployment, and it produces an actionable design rule: if all three cannot be avoided, narrow each one deliberately and know which you have granted. The permission asymmetries he lists — drafts but not sends, reads but not posts — are a concrete pattern that follows from it, and they are cheap to apply. The second durable observation is the promotion-versus-accumulation split in the memory design: log everything, promote a little, index the rest for retrieval. That is a structural answer to the context-window problem that does not depend on any model's context size, and it will outlast the specific window figures being advertised. Set against that, this is one practitioner describing his own unreleased system, with a self-reported time saving, promoting a paid workshop, and the video is roughly six months old — so its product comparisons and model assumptions should be treated as a snapshot of April 2026 rather than current.