FoundersOS
FoundersOS informs AI agents how your company works.
I run a small consulting shop with my co-founder. For months the same thing bugged me about every AI tool: it could draft a great client follow-up, but it had no idea who the client was, what we last talked about, or whether they still owed us money.
So I kept copy-pasting. Notes from one place, the last invoice from another, the deal stage from my own head. The model was smart and completely contextless.
We built Founders OS to fix that for us. It is an open-source MCP server that puts your real business context behind one connection: customers and contacts, tasks and projects, a double-entry financial ledger, RSS feeds, and a semantic memory layer. You point Claude or Cursor at it and the assistant can reason across all of it in a single answer.
The questions that made it click for me were the cross-domain ones a real operator actually asks:
"Which clients are behind on payment and when did I last talk to them?" reads the ledger and the CRM together.
"Draft a check-in for every account I have not touched in 30 days" reads interactions and contacts together.
"What did we decide about pricing last quarter?" hits the memory layer.
One question, multiple domains, one answer.
The part we care about most as founders: it runs on your own database. Your customer data, your ledger, your memory all live in a database you own.
It is live, MIT licensed, and free. Repo has setup for Claude Desktop and Cursor.
We are building this in public. If you run a small business or freelance and you self-host things, I would like to know the first cross-domain question you would ask it. Still finding new ones myself.
13 Comments
The distinction between remembering information and changing decisions is the one that matters most over time. A system that surfaces context but still leaves the judgment call to a human is just a faster assistant. A system that changes what someone actually does next, skip this lead, price it there, is a different category entirely. The pricing rule example is the clearest proof of that second kind, most tools never get past the first.
You're onto the part that matters most. It is not just remembering, it does make my decisions better over time, and the suggestions sharpen the more we work together. That has turned into real wins for us, not just faster lookups.
The clearest version is in the automation. We build playbooks that run a process, then feed each run's outcome back in, so the next run starts from what worked and what did not. The scoring gets better on its own. My contract pipeline is the proof: it learned which kinds to skip and which to lean into, and the shortlist keeps tightening. Same loop the pricing rule hints at, just running continuously.
Still my call at the end, but the system is genuinely raising the floor on those calls, not just speeding them up.
The self tightening shortlist is the detail that stands out. Most tools stop at recalling the outcome of the last run, yours is closing the loop so the next run starts smarter, that is a real design difference, not a feature difference. Curious how you keep the scoring honest as it tightens, do you ever go back and audit whether the loop is optimizing for the right signal, or does the pricing rule already guard against that on its own?
Constantly recalibrating with each retro. I have it setup to present things it passes on and the why. I then review it myself and provide additional input that results in potential updates. This happens less frequently, but still happens from time to time. I also do my own independent search and present my findings, as an additional input that the whole setup learns from as well.
We ran a market research playbook on Claude that ran every hour and took learnings back from each run as well as input from the team. It also got better by the day and surfaced some solid research and product ideas after a few weeks.
That cadence of hourly runs feeding back into the next run is the part most people skip. Most builders check the output once and move on, you built the retro in as a standing habit. Curious if the review step matters more for catching bad signal early, or for keeping your own judgment sharp as the loop takes on more decisions.
What I'd be watching is whether the core value is unified context or trusted decisions.
A lot of founders will immediately agree they want more context available to AI. The harder validation question is whether having more context actually changes decisions they would have made otherwise.
Those are very different signals, even though they can look identical early on.
One thing do see, is we spend way less time filling in more context in a session to get into the heart of the work, saving tokens and more importantly time.
We are also testing a new feature checkpoint, that creates a handoff for a new agent, tool, or session that knows the context and decisions from a previous session that can pick up without missing a beat.
This got us thinking a little, since we have been using it almost 2 months now. So will turn off and see how things go when going back to before Founders. :)
Happy to share the short version.
The thing I'd be watching isn't whether more context saves time.
It's whether, over time, the product proves its value by remembering information or by improving decisions.
Those can look like the same thing early on, but they don't always lead the business in the same direction.
That's the distinction I found interesting.
This clicked and got me thinking of a clear example I can point to internally...
The short version: for us it's turning into decision value, not just memory. The clearest example is our own lead pipeline. We run a repeatable playbook that hunts for consulting opportunities, scores each op, and then holds a short retro on what actually happened. When we lost two strong proposals because they were buried under a large number of already submitted bids and never even got viewed, that outcome became a rule, stop pursuing crowded listings. The next run, the system walked us away from three "good fit" leads it would have told us to chase a month earlier. It also relaxed a pricing rule based on what we'd learned, and that's the logic that led us to win one at a number we'd otherwise have screened out.
So it's not that the tool remembers more. It's that remembering the outcomes changed the playbooks behaviors. Skip this, pursue that, price it here. Same input, different decision, and we can point to the deals on both sides. This is a case where the decisions were changed and we have seen it reflected with real wins.
That example actually reinforced the direction I was thinking about.
It also made me realize the implication I'm seeing is much easier to explain against a real case like yours than in a public thread.
I'd rather not compress it into a few comments and lose the nuance.
If you're interested, what's the best email to reach you on?
Good point. Still learning internally as we use everything.
Interesting.
The fact you're still learning from your own internal use made me think about one implication that isn't obvious while the product is still taking shape.
I don't think I can explain the reasoning properly in a thread without oversimplifying it.
If you're interested, what's the best email to reach you on?
Happy to discuss, oversimplification will work here.