Notes on building a working memory that carries across meetings, projects, and teams.
Most knowledge workers don’t really have a memory problem, they have a retrieval problem. The notes exist somewhere, along with the decisions and the feedback, buried in a thread or a doc or a deck from three weeks ago. What’s missing isn’t the information itself. It’s that by the time you need it again, the version of you who captured it has already moved on.
I’ve been building a second brain with Claude for the better part of a year now. What started as a folder of markdown files and a few prompts has turned into something closer to a working partner, one that remembers who reports to whom, what was agreed last Thursday, and which projects are quietly slipping. As Lead Designer at Causeway, my work spans a lot of ground: multiple products, a distributed team, overlapping programmes, and a constant stream of incoming context. This is the system that lets me hold it all together.
What follows is a look at how I built it, what it actually does day-to-day, and why I’ve come to think the common “AI assistant” framing undersells what’s genuinely possible here.
The shift from notes to memory
The original Second Brain idea, popularised by Tiago Forte, was essentially personal knowledge management: you capture what you consume, organise it, and resurface it on demand. It worked because it gave structure to the chaos of everything you were reading and thinking about.
What’s different now is that the capture layer and the retrieval layer can be the same thing, and that thing can reason. A folder of files on its own is passive. A folder of files combined with an agent that reads, updates, and cross-references them while carrying context forward between sessions is something else entirely. Calling it a filing cabinet misses the point. It behaves more like a colleague who happens to have perfect recall of everything you’ve ever told them.
In practical terms, this has changed the question I ask myself when something new comes up. It used to be “where should I save this?” Now I just mention it in passing to Claude, and the system takes care of filing it properly and surfacing it again when the moment comes.
The working layer
At the heart of my setup is a short, curated memory file. It isn’t a database or a graph. It’s just a markdown document that describes, in plain language, who I am, who I work with, what I’m working on, and what I care about. It’s versioned and human-readable, and I can edit it directly whenever something changes.
Around that sits a small set of structured folders. One holds short profiles of teammates and key stakeholders, with their role, focus, and whatever context I’d otherwise lose track of over time. Another holds project notes covering current status, open questions, and recent decisions. A third covers general context, like the company glossary, internal shorthand, and organisational changes. Alongside all of that sits a single running task list.
The insight that took me longest to trust is that this layer really needs to stay small. Not every document belongs in working memory. What belongs here is the context I want Claude to have loaded when we sit down together, the sort of thing where without it our next conversation wouldn’t quite make sense. Everything else lives in long-term storage and gets pulled in only when it’s relevant.
What the daily rhythm looks like
The system really earns its keep in the daily routines.
Standups are the clearest example. Once a day I paste or dictate what the team shared: what each person is working on, what’s blocked, what shipped. A dedicated agent takes that raw dump and, in one pass, updates each teammate’s profile, refreshes the team-level project notes, and pulls any newly surfaced commitments into my task list. What used to be a post-meeting chore, the kind of admin that always got deferred until it became useless, now takes under a minute.
One-to-ones are the same pattern in reverse. Before a check-in I ask for a brief on the person: what they’ve been working on over the last few standups, what’s open, where they might be stuck, anything I should probably raise. The brief stays tight because the memory layer stays tight, and I walk into the conversation already oriented.
Meeting prep works in much the same way. It pulls the calendar invite, identifies the attendees, cross-references what I already know about each of them and any related projects, and then surfaces the relevant context as a short note. I stop arriving to calls trying to work out why they were scheduled in the first place.
At the end of each week I run a review covering what got done, what slipped, and what’s top of mind for the week ahead. It’s also the moment to clean up the working layer. Stale tasks get pruned, project statuses updated, anything that’s gone quiet when it shouldn’t have gets flagged. In practice it’s the same weekly review every decent productivity system has always recommended, except now I’m doing it with a collaborator who already knows what happened.
Beyond the day-to-day: specialised agents
The general-purpose second brain is really just the foundation. The more interesting work sits on top of it, in the form of domain-specific agents that plug into my team’s wider knowledge base.
The two I’ve invested in most heavily are a UX Research agent and a UX Writing agent, both connected to our Confluence spaces.
The research agent behaves like a senior user researcher who has read every study, usability report, persona, and piece of feedback the team has ever filed. When someone asks whether we’ve tested a particular pattern before, or what we know about how users behave in a specific context, instead of a three-person Slack thread and half an hour of hunting, I get a synthesised answer grounded in the actual research repository, with links back to the source material. The agent works in two modes. In query mode it answers questions. In ingest mode it evaluates new research for quality and files it in the right place, always with a human in the loop. Honestly, the second mode matters almost more than the first, because it means the knowledge base actually improves over time instead of becoming steadily more cluttered.
The writing agent does the equivalent job for our language and copy standards. What’s the correct term for a particular object in the product? How do we phrase a confirmation dialogue? What’s our tone on error states? The answers are all in Confluence, but they’re spread across dozens of pages that nobody has the bandwidth to fully internalise. The agent reads through them, applies the standards consistently, and when something new comes up that isn’t yet documented, it proposes an addition for review.
In effect, both agents are institutional knowledge turned into a colleague. They let a small team’s expertise scale across a much larger surface area.
Why this matters
The cliché about AI assistants is that they save you time. That’s true, but it’s a weak framing for what’s actually going on. Meetings stop opening with “remind me where we landed on this”, decisions don’t get quietly re-litigated because nobody remembered the first conversation, and you stop dropping things teammates told you three weeks ago.
What a second brain really changes is the quality of your decisions, because the context is always there when you need it.
There’s also a compounding effect that’s easy to miss early on. Every conversation becomes an opportunity to extend the memory, whether by refining a profile, updating a project status, or capturing a new piece of shorthand. Over months, the system becomes increasingly specific to you and your work. It learns your team, your products, the politics, the priorities. By comparison, starting fresh with a generic assistant feels a bit like working with a very smart stranger.
A few principles, if you want to try this
Start with a single memory file that you’d be comfortable handing to a new hire. If it doesn’t read that way, you probably haven’t found the right level of abstraction yet.
Be ruthless about what’s in the working layer. If a fact hasn’t been relevant in two months, it probably belongs in long-term storage rather than in your daily context.
Invest in the rituals before the tools. What makes this work isn’t clever prompting. It’s the standups, the one-to-ones, the weekly reviews, the meeting prep. The prompts are really just the interface to the habits underneath.
Wherever your team already keeps its knowledge, whether that’s Confluence, a wiki, or a shared drive, connect to it rather than duplicate it. You want the agent reading the source of truth, not becoming a parallel one.
And treat the memory as a living document. The single most common failure mode I’ve seen is people building the system once and then never updating it.
The value is in the maintenance.
Where this is going
My suspicion is that within a year or two, working without something like this will feel about as quaint as not having a calendar app. The technology is already here. What’s still catching up is the muscle for using it well: getting into the habit of externalising context, staying disciplined about curating it, and being willing to let a system hold things in your stead.
For now, the best time to start is on something small. Pick a single routine, whether that’s your weekly review, your team’s standup, or prep for your next meeting, and hand it off. See what it feels like to show up to that moment with full context already loaded. Then build outwards from there.
The brain you end up with a year later will surprise you.
Pedro Santos is Lead Designer at Causeway, where he writes about design systems, AI-native workflows, and the craft of running a team well.
Leave a Reply