I use the LLM-wiki pattern for a structured directory of topic folders of .md files, and made it also compatible with the Open Knowledge Format [1].
My agent (Hermes) responds to a made-up command "vaultize this doc/link/text, etc" to add new .md files in the right format in the right place. The agent does a pretty good job of maintaining the index.md file, cross-links, etc.
A Quartz website builder creates a static site on my server, each MD file is a web page, and rebuilds when a new file is added [2]. This setup gives me a useful knowledge base with a great UX - across all the devices on my Tailnet, no need to run Obsidian Sync, or Syncthing.
This system is simple and works well, but i think it could maybe benefit from a memory system like Honcho to make it more effective as it scales.
I have a folder called reports, plans, and code-reviews in each repo. I put my md files for agents there, and voila they're in the cloud along with my source code in git. I just talk to my local agent about these files and it finds things using grep and whatever. Done. No mcp or special server needed.
I've been pitched products like ozbrain before, but I've failed to see the need over what I already have. Seems like more complication for no gain to me.
That sounds like a solid setup for engineering. OzBrain is meant for not just the eng docs, but also the business and product docs. Also my personal stuff, ie my workout log is there, health analysis, etc. And I share our family docs with my wife, so all the kids stuff and our stuff is synced across devices. I think anybody that works on a computer, regardless of industry is going to be a heavy agent user in the future, and I'm building for all of them. Super smart people already have homegrown solutions that work for them.
How has traction been so far? And are there any valuable cross team/agent use cases you actually have experienced or are they theoretical?
I run https://smalldocs.org, which focuses on making Markdown a highly expressive space for agents (think slides, spreadsheets, charts, mermaid diagrams, etc.). I have built a local library which lives in the browser but reflects your local file system - explainer here: https://smalldocs.org/connect?return=%2Flibrary, demo here: https://smalldocs.org/library?demo=1. Which is pretty useful when you want to find local Markdown files.
However I am just about to introduce very similar functionality to yours - a cloud + agent access. Right now I don't know if this will actually be useful, but I think it will likely be something I can charge for. I have a few hundred developers that use SmallDocs on a weekly basis (https://smalldocs.org/analytics), but right now it's just a free local-first tool.
Do you have a solution for degradation in accuracy when compiling larger amounts of llm-produced text?
I am also building LLM knowledge/memory systems and I've been surprised how bad LLMs are, even SOTA models, at summarizing non-trivial input batches of text. They get things wrong, distort the underlying meaning or data, etc.
Divide and conquer essentially, is what I've found so far to work best. Split things into smaller and smaller chunks to independently be verified, double-check everything, then coalesce upwards with verified summarizations. Have benchmarks for every single task and sub-task that will happen everywhere a LLM is involved, so you can measure improvements. Takes a ton more effort and tokens in the system itself obviously, but if you're not paying per token, it seems to work pretty well, albeit feels slightly over-engineered already.
A constant challenge. Don't have a perfect solution for it yet, but importantly every change to any article logs who did it, what it did and the reasoning behind it. So I have enough data to work with as I continue to improve things.
I think the central question for a such memory system is whether we or the agents can find the relevant information and how to organize these data as changes continues to come in. Would we miss something in the retrieval process? How do we organize the information so they stay actual and correct without piling up the garbage? Of course we can continue to concatenate the data and tag them with version and date, but then we have to face the problem of extracting the relevant information in a short time. If we delegate that problem to a LLM, long context retrieval performance will degrade and the cost will explode.
That is the reason why we condense the information in the first place. Forgetting + Synthesizing are the necessary parts of learning and basically with memory + smart retrieval we want to build a learning system.
What I'm building has a regular maintenance it runs across the knowledge. A. to chunk long articles down into smaller chunks or information with good routing. B. To review the latest thinking to make sure old thinking is deprecated and linked.
This will be the big challenge with this. Storing/Retrieving works fine across hundreds of articles... I have more than 500 right now just from OzBrain and a bit of the thing I was building before. When it becomes thousands with dozens being added all the time, the maintenance will become more of a necessity.
I lean a little bit towards store everything because the system's abilities are changing so fast right now, that having our previous thinking or reasoning is useful in being able to improve or correct current assumptions based on previous data.
Hi, I really liked your idea. It is really helpful for companies or teams that use multiple models. Also, the design of the site was very good and I really enjoyed it.
A quick side note: I opened the page and my brain went into "It's an AI-landing-page there is no value there"-mode. That added quite a lot of friction to start reading it.
Me too. It demanded deep digging to find out how it was done and how is it different from other products. And my brain was resisting all the way through!
I wish the author had made a mental image like “OzBrain is a Zettelkasten system built with AI background maintenance” then things will become much easier for the readers to understand.
our approach was to build a data lake that sucks company data into clickhouse and staple that to a knowledge store. this way the brain has a stream of live facts and builds knowledge around it. we gave up on trying to make the knowledge store human-readable -- i totally think there could be something there, but for now we just care about enhancing the agent you're using. it makes my claude code very good at debugging and gives everyone a way to vibecode dashboards and small internal tools with real data.
i also run a personal instance for my wife and I that sucks in monarch money and gmail. mostly use it to chat through big money moves.
Cool. If I'm reading it right, it only allows read access? How do you get knowledge into the brain?
I'm assuming that the content you put in is all agent driven. Source files (ie, a transcript, a data log, stuff that shouldn't eery change) get recorded but the articles are some kind of agent reasoning on top of it. I don't have any interface to edit an article. Your agent does it.
And yeah I agree about not building for human consumption. The agents create and consume vasly more data than we can.
I don't do any ingestion, I figure out can automate that in a routine or a zap or whatever you want.
Would you consider this a different type product/benefit than all the "memory" things we have seen popping up everywhere?. Is it different just because it lives in the cloud? To me it feels like a different thing than memory.
I think they’re similar but different. Memory is usually single user focused, a summary of specific facts or instructions. OzBrain is everything that was captured, reasoned, promoted, etc. and auditable record of what the latest thinking is and why. When agents are the primary user you need a way to capture why they ended up at where they ended up. Memory is more like the filtered summary of everything it has saved as important.
It’s very encouraging to see serious attempts at addressing continuity between agents’ outputs. Right now, everyone seems to be figuring out their own way of maintaining consistency across sessions without endlessly over-contextualizing each new one.
This feels like an important layer of the emerging agent stack, and I think this Show HN will be useful to a lot of people working through exactly that problem.
I’m not sure I get the value over Obsidian, can you explain the static file issue? Only happens at 7K+ individual files? What happens if you always conjoin files?
Obsidian would fall into the same answer as how is this different than gBrain. Obsidian is a powerful and configurable... but requires more work to maintain and sharing knowledge with others is more difficult. I want this to be a super easy way for agents to connect to my knowledge, and make it easy for me to share my chunks of knowledge with my teammates and their agents. Just MCP in and have your agents get to work.
I'd say gBrain is also more structured to the priorities of a VC and less of a general-purpose graph-based memory. There are tons of hard-coded regexes that may work beautifully for Garry's priorities and workflow that don't fit other use cases, and are probably really brittle even if you're a VC who uses different words in your notes.
Yeah, I wouldn't put your crypto wallet into OzBrain or anything... this is more the day to day operation of your business or personal life. While that is also valuable, our data is already sitting on a lot of servers so might as well make it useful for you and your agents.
Yeah, close. But all handled so a user can just focus on connecting the MCP and doing work. Goes to my answer elsewhere here about different between gbrain / llm-wiki… those are highly configurable and powerful, but require technical knowledge and time. I think the vast majority of tech workers will need “that for dummies” ie this just works for them.
Almost all of this is stuff I have indeed "frankenstein[ed]" for myself, so consider this comment a +1 on market fit, there!
That also gives me a reason to pause, tho; the pitch in general is as solid as it can be on a site with markdown turned off (why, lord, why), but as a format minutiae megafan, I was left a little dissapointed. Where do you/OzBrain stand on Markdown formats? Could I use Sphinx with this, in rST and/or native MyST? Can it generate plain PDFs, fancy PDFs, or even animated static sites? etc. etc. etc. Not trying to gotcha, just curious to hear your thoughts & dreams on the topic!
It seems like some subculture(s) of SWE/SV/YC/AI has landed on obsidian-ish markdown with lots of wikilinks as the presumed default, which makes sense. So I'm assuming it's the same here. But also, your 'OzBrain vs. Obsidian' page does describe one difference as 'Markdown export anytime' vs. 'Markdown on disk' -- presumably that's just a hedge about hosting paradigm rather than a comment on the persistent format?
P.S. You're likely aware but there's at least one other company using Oz -- Warp's coding agent. Have you considered renaming this to something unimpeachable like DeepReasoningBrain? ;)
P.P.S. Holy hell your `eng-flow` thing is incredible. Maybe I'm behind the times, but... I mean, has anyone else processed how close we are to Minority Report and Iron Man?!
Along with my conversations with the 75 founders, there were two other distinct camps that I saw... those that care about the display and UX for them to see their .md files... and those (of which I am in) that don't care, I don't want to see the markdown, it is for my agents to see and relay to me what is important.
OzBrain is text only, and basic markdown formatting (OKF). No fancy PDFS, etc. BUT that is what your agent is for. If you want to generate a fancy PDF, have an agent reference the relevant articles and generate what you want. I've considered a lot of additional services like automatic ingestion, ie every call transcript auto-ingested as a source article in the brain... but you can do that with routines or Zapier. My focus is on the infra of the data getting to and from your agents.
I think Karpathy's llm-wiki was a boost to the wiki-markdown club, and it makes a ton of sense why a technical person would adopt that. They're already veru comfortable with github and moving files with terminal commands. They're not my target audience right now, but maybe when we have more robust brain maintenance they'll decide it's jsut easier to use OzBrain and not maintain their own thing.
P.S. In true move fast break things mode... I spent a good 15min working on the name. :) It works for now and if it really works well for people and they love it, the name won't matter so much.
P.P.S. Thanks, it's either genius or incredibly stupid... hard to know these days as stuff moves so quickly and your AI tells you you're so smart. It's what I HAD to build, because I don't speak any of the current languages. I lost my coding skills long ago, so at a point where it might make sense for a smart engineer to review or approve something... I needed to insert an agent that actually knows what it's talking about and understands how to make a good decision. That thing is constantly improving or breaking... I tried to automate one more step a few days ago and have been paying the price and bug fixing my thing that builds things, instead of just BUILDING THE THINGS! ugh.
P.P.P.S. I mean I used OzBrain to build OzBrain and make that eng flow work. If you think something in there would be useful, I'd just point an agent at it that is connected to your whole workspace/flow and ask it what is useful/dumb.
*Bonus point. Because my whole brain is in OzBrain and it knows what I'm building, why, how... I can take a talk transcript like Garry's from Startup School and just ask an agent "Save this transcript in the brain as a source and then review it and show me where this validates or invalidates some of my thinking. And what else would be interesting for me to consider in my broader work."
While I agree with you on most of what you’re saying, I think there is still an audience outside of your viewpoint that may see value. But thanks for sharing your insights! Super helpful.
I use the LLM-wiki pattern for a structured directory of topic folders of .md files, and made it also compatible with the Open Knowledge Format [1].
My agent (Hermes) responds to a made-up command "vaultize this doc/link/text, etc" to add new .md files in the right format in the right place. The agent does a pretty good job of maintaining the index.md file, cross-links, etc.
A Quartz website builder creates a static site on my server, each MD file is a web page, and rebuilds when a new file is added [2]. This setup gives me a useful knowledge base with a great UX - across all the devices on my Tailnet, no need to run Obsidian Sync, or Syncthing.
This system is simple and works well, but i think it could maybe benefit from a memory system like Honcho to make it more effective as it scales.
[1] https://cloud.google.com/blog/products/data-analytics/how-th...
[2] https://quartz.jzhao.xyz/
I have a folder called reports, plans, and code-reviews in each repo. I put my md files for agents there, and voila they're in the cloud along with my source code in git. I just talk to my local agent about these files and it finds things using grep and whatever. Done. No mcp or special server needed.
I've been pitched products like ozbrain before, but I've failed to see the need over what I already have. Seems like more complication for no gain to me.
Am I missing something?
That sounds like a solid setup for engineering. OzBrain is meant for not just the eng docs, but also the business and product docs. Also my personal stuff, ie my workout log is there, health analysis, etc. And I share our family docs with my wife, so all the kids stuff and our stuff is synced across devices. I think anybody that works on a computer, regardless of industry is going to be a heavy agent user in the future, and I'm building for all of them. Super smart people already have homegrown solutions that work for them.
How has traction been so far? And are there any valuable cross team/agent use cases you actually have experienced or are they theoretical?
I run https://smalldocs.org, which focuses on making Markdown a highly expressive space for agents (think slides, spreadsheets, charts, mermaid diagrams, etc.). I have built a local library which lives in the browser but reflects your local file system - explainer here: https://smalldocs.org/connect?return=%2Flibrary, demo here: https://smalldocs.org/library?demo=1. Which is pretty useful when you want to find local Markdown files.
However I am just about to introduce very similar functionality to yours - a cloud + agent access. Right now I don't know if this will actually be useful, but I think it will likely be something I can charge for. I have a few hundred developers that use SmallDocs on a weekly basis (https://smalldocs.org/analytics), but right now it's just a free local-first tool.
Code available here: https://github.com/espressoplease/smalldocs
Do you have a solution for degradation in accuracy when compiling larger amounts of llm-produced text?
I am also building LLM knowledge/memory systems and I've been surprised how bad LLMs are, even SOTA models, at summarizing non-trivial input batches of text. They get things wrong, distort the underlying meaning or data, etc.
Divide and conquer essentially, is what I've found so far to work best. Split things into smaller and smaller chunks to independently be verified, double-check everything, then coalesce upwards with verified summarizations. Have benchmarks for every single task and sub-task that will happen everywhere a LLM is involved, so you can measure improvements. Takes a ton more effort and tokens in the system itself obviously, but if you're not paying per token, it seems to work pretty well, albeit feels slightly over-engineered already.
A constant challenge. Don't have a perfect solution for it yet, but importantly every change to any article logs who did it, what it did and the reasoning behind it. So I have enough data to work with as I continue to improve things.
I think the central question for a such memory system is whether we or the agents can find the relevant information and how to organize these data as changes continues to come in. Would we miss something in the retrieval process? How do we organize the information so they stay actual and correct without piling up the garbage? Of course we can continue to concatenate the data and tag them with version and date, but then we have to face the problem of extracting the relevant information in a short time. If we delegate that problem to a LLM, long context retrieval performance will degrade and the cost will explode.
That is the reason why we condense the information in the first place. Forgetting + Synthesizing are the necessary parts of learning and basically with memory + smart retrieval we want to build a learning system.
What I'm building has a regular maintenance it runs across the knowledge. A. to chunk long articles down into smaller chunks or information with good routing. B. To review the latest thinking to make sure old thinking is deprecated and linked.
This will be the big challenge with this. Storing/Retrieving works fine across hundreds of articles... I have more than 500 right now just from OzBrain and a bit of the thing I was building before. When it becomes thousands with dozens being added all the time, the maintenance will become more of a necessity.
I lean a little bit towards store everything because the system's abilities are changing so fast right now, that having our previous thinking or reasoning is useful in being able to improve or correct current assumptions based on previous data.
Hi, I really liked your idea. It is really helpful for companies or teams that use multiple models. Also, the design of the site was very good and I really enjoyed it.
A quick side note: I opened the page and my brain went into "It's an AI-landing-page there is no value there"-mode. That added quite a lot of friction to start reading it.
Me too. It demanded deep digging to find out how it was done and how is it different from other products. And my brain was resisting all the way through!
I wish the author had made a mental image like “OzBrain is a Zettelkasten system built with AI background maintenance” then things will become much easier for the readers to understand.
Also thanks for doing the mental hurdling to get thru! I will work on that image...
Noted! Thanks. I appreciate you getting thru it. What do you think would have made it more clear/faster?
100%! It is a real mental block!
What do you think would improve that? Different language? More visuals?
nice :)
> love to hear how you did it
this is ours we built for Hedgy https://setoku.com
our approach was to build a data lake that sucks company data into clickhouse and staple that to a knowledge store. this way the brain has a stream of live facts and builds knowledge around it. we gave up on trying to make the knowledge store human-readable -- i totally think there could be something there, but for now we just care about enhancing the agent you're using. it makes my claude code very good at debugging and gives everyone a way to vibecode dashboards and small internal tools with real data.
i also run a personal instance for my wife and I that sucks in monarch money and gmail. mostly use it to chat through big money moves.
Cool. If I'm reading it right, it only allows read access? How do you get knowledge into the brain?
I'm assuming that the content you put in is all agent driven. Source files (ie, a transcript, a data log, stuff that shouldn't eery change) get recorded but the articles are some kind of agent reasoning on top of it. I don't have any interface to edit an article. Your agent does it.
And yeah I agree about not building for human consumption. The agents create and consume vasly more data than we can.
I don't do any ingestion, I figure out can automate that in a routine or a zap or whatever you want.
This is interesting.
Would you consider this a different type product/benefit than all the "memory" things we have seen popping up everywhere?. Is it different just because it lives in the cloud? To me it feels like a different thing than memory.
I think they’re similar but different. Memory is usually single user focused, a summary of specific facts or instructions. OzBrain is everything that was captured, reasoned, promoted, etc. and auditable record of what the latest thinking is and why. When agents are the primary user you need a way to capture why they ended up at where they ended up. Memory is more like the filtered summary of everything it has saved as important.
How do you stop agents from working over the same document at the same time? We do markbase for this exact reason.
It’s very encouraging to see serious attempts at addressing continuity between agents’ outputs. Right now, everyone seems to be figuring out their own way of maintaining consistency across sessions without endlessly over-contextualizing each new one.
This feels like an important layer of the emerging agent stack, and I think this Show HN will be useful to a lot of people working through exactly that problem.
What a surprisingly lovely comment section. I love the curiosity and positivity. Hope you have a great day.
I’m not sure I get the value over Obsidian, can you explain the static file issue? Only happens at 7K+ individual files? What happens if you always conjoin files?
Obsidian would fall into the same answer as how is this different than gBrain. Obsidian is a powerful and configurable... but requires more work to maintain and sharing knowledge with others is more difficult. I want this to be a super easy way for agents to connect to my knowledge, and make it easy for me to share my chunks of knowledge with my teammates and their agents. Just MCP in and have your agents get to work.
I'd say gBrain is also more structured to the priorities of a VC and less of a general-purpose graph-based memory. There are tons of hard-coded regexes that may work beautifully for Garry's priorities and workflow that don't fit other use cases, and are probably really brittle even if you're a VC who uses different words in your notes.
I have been looking for something like this but would actually want to self host due to the potential value/privacy of the data.
Yeah, I wouldn't put your crypto wallet into OzBrain or anything... this is more the day to day operation of your business or personal life. While that is also valuable, our data is already sitting on a lot of servers so might as well make it useful for you and your agents.
What's stopping you from putting your md files for agents right into your git repo along with the rest of your project files?
I would like to have more of a global memory for personal assistant type of agents. Auto updated and maintained. Browsable.
I'm Johnny.Decimal. [0]
I use an Obsidian vault and my system. "It's at 23.16", I tell Claude. From that it can instantly find my notes and files.
No extra software needed. Just some basic structure. Claude loves it. [1]
Oh yeah, and to keep conversation context contained so you can /resume and so on, just
[0]: https://johnnydecimal.com[1]: https://www.youtube.com/watch?v=mZAT0Ft--wE
Cool. Johnny Decimal sounds badass too, like maybe if an agent loses some of my work it will hunt it down and kill beat it up ;)
Are you seeing engineers use it or more every day people getting the hang of it to?
much needed, will give it a crack - congrats on shipping!
This is a fascinating place in the stack to sit. I need to dig in a lot more. Nice start.
Good luck with the showing!
I have been thinking about this idea for a while. Cool work.
Thanks! Where did you end up With your thinking? Would love to have you try it and tell me where you think k it could be better.
So is this cloud sync for my Md files? Who pays for the diffing and versioning?
In a way yes. A hosted llm-wiki, where I handle the diffing, versioning and audit log of what was changed, by what agent and why.
So a git repo + md files?
Yeah, close. But all handled so a user can just focus on connecting the MCP and doing work. Goes to my answer elsewhere here about different between gbrain / llm-wiki… those are highly configurable and powerful, but require technical knowledge and time. I think the vast majority of tech workers will need “that for dummies” ie this just works for them.
Almost all of this is stuff I have indeed "frankenstein[ed]" for myself, so consider this comment a +1 on market fit, there!
That also gives me a reason to pause, tho; the pitch in general is as solid as it can be on a site with markdown turned off (why, lord, why), but as a format minutiae megafan, I was left a little dissapointed. Where do you/OzBrain stand on Markdown formats? Could I use Sphinx with this, in rST and/or native MyST? Can it generate plain PDFs, fancy PDFs, or even animated static sites? etc. etc. etc. Not trying to gotcha, just curious to hear your thoughts & dreams on the topic!
It seems like some subculture(s) of SWE/SV/YC/AI has landed on obsidian-ish markdown with lots of wikilinks as the presumed default, which makes sense. So I'm assuming it's the same here. But also, your 'OzBrain vs. Obsidian' page does describe one difference as 'Markdown export anytime' vs. 'Markdown on disk' -- presumably that's just a hedge about hosting paradigm rather than a comment on the persistent format?
P.S. You're likely aware but there's at least one other company using Oz -- Warp's coding agent. Have you considered renaming this to something unimpeachable like DeepReasoningBrain? ;)
P.P.S. Holy hell your `eng-flow` thing is incredible. Maybe I'm behind the times, but... I mean, has anyone else processed how close we are to Minority Report and Iron Man?!
P.P.P.S. Is any part of that/this OS?
Along with my conversations with the 75 founders, there were two other distinct camps that I saw... those that care about the display and UX for them to see their .md files... and those (of which I am in) that don't care, I don't want to see the markdown, it is for my agents to see and relay to me what is important.
OzBrain is text only, and basic markdown formatting (OKF). No fancy PDFS, etc. BUT that is what your agent is for. If you want to generate a fancy PDF, have an agent reference the relevant articles and generate what you want. I've considered a lot of additional services like automatic ingestion, ie every call transcript auto-ingested as a source article in the brain... but you can do that with routines or Zapier. My focus is on the infra of the data getting to and from your agents.
I think Karpathy's llm-wiki was a boost to the wiki-markdown club, and it makes a ton of sense why a technical person would adopt that. They're already veru comfortable with github and moving files with terminal commands. They're not my target audience right now, but maybe when we have more robust brain maintenance they'll decide it's jsut easier to use OzBrain and not maintain their own thing.
P.S. In true move fast break things mode... I spent a good 15min working on the name. :) It works for now and if it really works well for people and they love it, the name won't matter so much.
P.P.S. Thanks, it's either genius or incredibly stupid... hard to know these days as stuff moves so quickly and your AI tells you you're so smart. It's what I HAD to build, because I don't speak any of the current languages. I lost my coding skills long ago, so at a point where it might make sense for a smart engineer to review or approve something... I needed to insert an agent that actually knows what it's talking about and understands how to make a good decision. That thing is constantly improving or breaking... I tried to automate one more step a few days ago and have been paying the price and bug fixing my thing that builds things, instead of just BUILDING THE THINGS! ugh.
P.P.P.S. I mean I used OzBrain to build OzBrain and make that eng flow work. If you think something in there would be useful, I'd just point an agent at it that is connected to your whole workspace/flow and ask it what is useful/dumb.
*Bonus point. Because my whole brain is in OzBrain and it knows what I'm building, why, how... I can take a talk transcript like Garry's from Startup School and just ask an agent "Save this transcript in the brain as a source and then review it and show me where this validates or invalidates some of my thinking. And what else would be interesting for me to consider in my broader work."
Meh
While I agree with you on most of what you’re saying, I think there is still an audience outside of your viewpoint that may see value. But thanks for sharing your insights! Super helpful.