Very interesting. I teach AI to business users in Cowork mostly. They build a Work OS with one workspace per domain (sales, mktg, ops, etc) and run their day-to-day workflows from there. Workspace => your project
I’d love to bring a second brain to my students that understands theim, their business, and daily work, but it has to be self-managed and easy to use.
I understand you’re developer focused. What’s your take on bringing this second brain to a Cowork business use case? Realistic to expect a plug-and-play with a bit of help at setup? The LLM Wiki approach offers a single mechanism to query context on-demand and it scales. I love that part!
~two years ago, I got inspired by Tiago's Forte PARA method, which can be applied to any domain, so I totally believe you can adapt this to any knowledge work.
For example, create an area for sales, mktg, ops, etc., with an attached wiki to them and spin up new projects on them for each task
Should work with Cowork, Claude Code or any harness. That's the beauty of .md files and wikis.
I saw you mentioned PARA in the article. It's hard to tell if this is the right approach or if I simply stick to Karphaty's basic LLM Wiki design. It's a real choice and beside you, nobody I know of is using PARA and providing free agents/skills. I'm also extremely cautious before adopting new models/tools/logic in my AI stack.
If I decided t adopt PARA and your agents, I am not sure if it'd run in 2 hours and if I'd understand the logic behind it without blocking a few days. I also don't want to own the agents/skills fully. I just tried Blotato for social media and had to rewrite all the skills. Frustrating.
md files i not an issue, 100% of my student's Work OS run in workpsaces with workflows, templates, knowledge structured as .md. My challenge is simple: can I auto-deploy it to the student's Cowork instance and have it run like magic? I already do that for my Work OS (I'm like a MSP for Cowork).
PS: I'm an ex-software engineer and spent 12 years at Salesforce (app+platform).
10,994 notes and most of them dead weight until an agent could actually query them is the real argument here. I keep my own vault lean for the same reason: a note nobody acts on is just archived data, whether it's a markdown file or a finished thing sitting in the shop waiting for someone to notice it. The wiki-as-agent-memory layer is the first setup I've seen that makes the vault do something instead of just holding things.
Pretty close. Plain markdown on disk (Obsidian, PARA folders) and an agent that reads and writes those files directly, no separate database. What made it click was one index file the agent loads first: one line per fact, link to the full note. Without that entry point it just re-reads everything and still misses what matters.
That's the missing layer for me actually. Right now PARA folders are my only scoping, nothing indexed per project the way you describe. How does the agent decide which wiki to load first?
That per-project attachment is exactly the piece I’m missing. My index loads flat at the start of every session, so the agent hauls the whole vault even when it only needs one project. Scoping the wiki to the project would cut that noise. How do you keep the wiki-of-wikis from turning into another layer you maintain by hand?
Very interesting. I teach AI to business users in Cowork mostly. They build a Work OS with one workspace per domain (sales, mktg, ops, etc) and run their day-to-day workflows from there. Workspace => your project
I’d love to bring a second brain to my students that understands theim, their business, and daily work, but it has to be self-managed and easy to use.
I understand you’re developer focused. What’s your take on bringing this second brain to a Cowork business use case? Realistic to expect a plug-and-play with a bit of help at setup? The LLM Wiki approach offers a single mechanism to query context on-demand and it scales. I love that part!
~two years ago, I got inspired by Tiago's Forte PARA method, which can be applied to any domain, so I totally believe you can adapt this to any knowledge work.
For example, create an area for sales, mktg, ops, etc., with an attached wiki to them and spin up new projects on them for each task
Should work with Cowork, Claude Code or any harness. That's the beauty of .md files and wikis.
What do you think?
I saw you mentioned PARA in the article. It's hard to tell if this is the right approach or if I simply stick to Karphaty's basic LLM Wiki design. It's a real choice and beside you, nobody I know of is using PARA and providing free agents/skills. I'm also extremely cautious before adopting new models/tools/logic in my AI stack.
If I decided t adopt PARA and your agents, I am not sure if it'd run in 2 hours and if I'd understand the logic behind it without blocking a few days. I also don't want to own the agents/skills fully. I just tried Blotato for social media and had to rewrite all the skills. Frustrating.
md files i not an issue, 100% of my student's Work OS run in workpsaces with workflows, templates, knowledge structured as .md. My challenge is simple: can I auto-deploy it to the student's Cowork instance and have it run like magic? I already do that for my Work OS (I'm like a MSP for Cowork).
PS: I'm an ex-software engineer and spent 12 years at Salesforce (app+platform).
10,994 notes and most of them dead weight until an agent could actually query them is the real argument here. I keep my own vault lean for the same reason: a note nobody acts on is just archived data, whether it's a markdown file or a finished thing sitting in the shop waiting for someone to notice it. The wiki-as-agent-memory layer is the first setup I've seen that makes the vault do something instead of just holding things.
Yes, exactly! What's your setup more exactly? Is it similar?
Pretty close. Plain markdown on disk (Obsidian, PARA folders) and an agent that reads and writes those files directly, no separate database. What made it click was one index file the agent loads first: one line per fact, link to the full note. Without that entry point it just re-reads everything and still misses what matters.
Exactly! And if your Obsidian vault gets too large, you can map it to scoped Wikis per project. This works like a charm.
That's the missing layer for me actually. Right now PARA folders are my only scoping, nothing indexed per project the way you describe. How does the agent decide which wiki to load first?
I always scope my work per project, so the agent automatically knows to pick the wiki attached to that project.
Recently I started exploring the idea of wiki's of wiki's to start composing them, but still a wip
That per-project attachment is exactly the piece I’m missing. My index loads flat at the start of every session, so the agent hauls the whole vault even when it only needs one project. Scoping the wiki to the project would cut that noise. How do you keep the wiki-of-wikis from turning into another layer you maintain by hand?