Every AI tool I tried gave me good one-off answers, then reset to zero the next session, so I kept re-explaining my own company to it. Built Pythe to fix that specific thing: give it a goal, it builds a staged roadmap (Ideation to Scale) and actually retains your positioning, ICP and competitors across sessions instead of forgetting.
It also ships via MCP/REST so it can sit inside Claude, ChatGPT, Cursor or Lovable instead of being another tab to remember to open.
Live at pythe.app, first 50 founders get 30% off for life while I figure out pricing. Would genuinely value feedback from people who've actually shipped something here, good or brutal.
This is the same real-time-vs-permanent-memory tension we hit building AI-assisted campaigns across a bunch of small SaaS products - a fix from one incident quietly becomes gospel forever unless something forces a re-check. What's worked for us is treating memory as a claim with a timestamp, not a fact: before acting on something recalled, re-verify it against current state rather than trusting it outright. Curious whether Pythe surfaces confidence/recency on retrieved context, or presents everything with equal weight regardless of age.
Good framing, "a claim with a timestamp, not a fact" is a better way to put it than anything I've written about this. Honest answer: I haven't built confidence/recency surfacing yet, right now it treats retrieved context as equally trustworthy regardless of age, which is exactly the gap you're pointing at. Noting it as real feedback rather than promising it's solved. Appreciate you sharing how you handled it on the campaigns side.
The re-explaining-your-own-company problem is real. I keep a pinned doc I paste into new sessions just to avoid repeating ICP and positioning every time. One thing I'd want to know before trusting a memory layer: when positioning shifts (and it does every few weeks early on), does Pythe version the old context or just overwrite it? Stale memory feels worse than none.
Straight answer: it overwrites right now, no versioning yet. You're right that's risky early on when positioning is still moving every few weeks, stale-and-silent is worse than just asking again. Adding version history to the list because of this, not because I had it planned.
shipping via MCP instead of another tab is the smart half imo. we went the same way w/ scout7.ai (https://scout7.ai?utm_source=indiehackers&utm_medium=comments). do founders actually find it inside claude, or do u still have to tell them?
Checked out scout7.ai, similar bet on the same delivery problem. Honestly right now you still have to tell people it lives inside Claude/ChatGPT/Cursor, nobody's finding it there on their own yet. That's more an awareness problem than a product one at this stage, but I don't want to oversell it as seamless discovery, it isn't yet.
The MCP/REST angle is the part I care about most as a builder: if Pythe sits inside Claude, Cursor and Lovable at the same time, who wins when two tools write conflicting context in the same session? Multi-writer memory is where these systems usually fall apart — last write wins silently corrupts the roadmap. Curious how you handle conflict resolution (or whether you just accept the risk for now).
Fair to call out, and honest answer is I accept the risk for now, last write wins, no conflict resolution. With one user that's rarely triggered since you're usually only actually working in one tool at a time, but you're right it's a real gap the moment two agents write in the same window. Not something I have a good answer for yet.
The pushback angle raises a useful distinction: an idea I'm exploring isn't a decision I've made. If I say 'maybe we should target agencies,' I'd want Pythe to keep that as a hypothesis, not silently update my ICP. Does it ask for confirmation before a conversation changes the roadmap's underlying assumptions?
That's exactly the right distinction and honestly not one I've built for. Right now if you say "maybe we should target agencies" in conversation, it can end up folded into the roadmap as if it were settled. It should treat that as a hypothesis and ask before it changes underlying assumptions, but it doesn't do that reliably yet. Good one to fix.
Should mention howeevr Pythe does always ask before updating your roadmap and doesCompletely agree, and "see and edit it easily or people find workarounds" matches what I've seen too. There's no "what this remembers" view right now, it's a real gap versus DictaFlow's approach. Trust seems to come from visibility more than from the memory being technically correct, that's a useful reframe. explicitly explain any changes it made after.
Sorry, that last reply above posted garbled (a copy-paste mix-up on my end). To clean it up: yes, Pythe should ask before folding "maybe we should target agencies" into the roadmap as a settled assumption, it doesn't do that reliably yet, so thanks for flagging it.
The re-explaining problem resonates, but stale context worries me too. With DictaFlow, I've found that people need to see and edit useful context easily. If they can't, they stop trusting it and find ways around it. Version history and a clear "what this remembers" view would make the promise much easier to trust.
Completely agree, if people can't see and edit what it's holding, they stop trusting it and route around it. There's no "what this remembers" view right now, that's a real gap versus what you're describing with DictaFlow. Trust seems to come from visibility more than the memory being technically correct.
The "30% off for life" offer is the part I would kill before launch. You are permanently repricing your most engaged early cohort at a number you set before you knew what the product was worth, and those are exactly the accounts you will want to raise prices on later. Give the first 50 a few free months or a founding-member badge instead, both cost you less and neither one puts a permanent ceiling on the account.
Fair, and you're right. Killed the "30% off for life" line entirely, it's just a flat £19/month base plan now, no discount games, no permanent ceiling to regret later. Appreciate the push on this.
Most "AI memory" demos are a bigger context window with better marketing.
What actually sticks is a tiny pipeline, not a model feature: decide what's worth keeping, park it somewhere, retrieve it later, and have a rule for when to stop keeping it. Skip that last part and you just accumulate sludge until the agent gets worse.
I tore the word "memory" into the five mechanisms people mash together, then wrote a ~90-line version that does the job:
https://medium.com/data-science-collective/i-built-the-thing-that-lets-ai-remember-you-it-took-90-lines-c301a96cdfac?sk=f87978834c801da16d80c4799b467edc
Curious how you're handling the forget side. That's the bit most demos skip.
Fair question, probably the most important one here. Honest answer: I don't want to overclaim confidence/recency handling before I've stress-tested it against a real positioning change, so I'll come back with a real answer rather than a marketing one. Bigger picture: memory is genuinely the least interesting part of what we built, it's plumbing so you don't have to re-paste your own ICP every session. What I'd actually value feedback on is the other half, the staged roadmap and the pushback on what's worth doing next. Does that sound useful to you, or is that a solved problem for you already?
Nice post!
Thanks, appreciate you taking a look!
The “push back like a cofounder” part is what caught my attention. Remembering context is useful, but having the AI actually tell you when an idea probably isn’t worth building seems much more valuable. Have you found that founders prefer the pushback, or do they mostly use it for brainstorming?
Honestly more brainstorming than pure pushback so far, founders seem to want it to argue with them on scope ("do you really need X before you have 5 customers") more than kill ideas outright. The hard cases are when it's confidently wrong, that's the risk with any of this.
This sounds like a general-purpose memory layer. I'm wondering how it differs from other memory layer applications out there.
I've actually been following a lot of memory layer apps, but I haven't really found any practical use cases yet because I can just have AI read my website directly. Plus, tools like Codex or Claude already have built-in memory that remembers these things.
The only real difference would be whether there is a way to flexibly switch between different software. For example, once I've built up enough memory in one tool, can I just switch directly to another?
Fair pushback, it's not a general-purpose memory layer though, that's actually not the point of it. The memory is just plumbing so you don't have to re-paste your ICP every session. The actual product is the staged roadmap plus the pushback on what's worth building next, which isn't something reading your website gives you. On switching tools: since it ships via MCP/REST, the context travels with you, you're not locked into one client.
This hits home — I got tired of re-explaining my own company to every AI tool too. Respect for shipping Pythe and taking the feedback loop on the chin; the "push back like a cofounder" angle is genuinely the strongest part, and context is what makes that pushback relevant. Curious what context you persist — positioning doc, ICP notes, competitor matrix? I solve the same problem from the other direction: plain-text CLAUDE and SKILL instruction files that travel with the repo, so any agent reads the same context every session. Packaged 76+ of those workflows into $7 packs.
The context I persist is basically that: positioning, ICP, competitor notes, plus the roadmap state itself. Your CLAUDE/SKILL packs approach is interesting, that's static and portable, mine is more live and gets reasoned over rather than just read. Different tradeoffs, not obviously better, just easier if you don't want to hand-maintain the files yourself. What's in your $7 packs, workflows per niche?
The 'remembers between sessions' pitch is the right one to lead with, that reset-to-zero problem with every AI tool is real and something I've felt myself. One thing I'd push on: 'ships via MCP/REST so it sits inside Claude, ChatGPT, Cursor or Lovable' is a strong technical differentiator, but it's buried after the roadmap pitch, that integration point is probably the actual reason someone switches from just re-explaining context every time, I'd lead with that rather than the staged roadmap feature.
Good push, and honestly I think you're both right depending on the reader. Just put up a new post that leads with "staged roadmap + pushback" instead, since a few people pointed out the memory framing undersold the actual product. Curious if that lands better or worse for you than leading with MCP/REST.
The persistent context and staged roadmap approach sounds genuinely useful, especially for founders who are tired of repeating the same company details every session. MCP/REST support is also a nice touch. I’d be interested to see how well the context retention works as a startup evolves.
Thanks. Honestly that's the open question, I haven't stress-tested it through a real positioning pivot yet. Right now it overwrites rather than versions, so if your context shifts fast early on, it can go stale-and-confident instead of stale-and-honest, which is worse. Version history is on the list because of feedback like this.
The memory solves a real annoyance, but I’m curious whether founders actually make different decisions because Pythe remembers the context, or whether it mainly saves them from re-explaining the same things each session.
Genuinely mixed so far. Mostly it saves the re-explaining, but a few times someone's typed something like "maybe target agencies" as a passing thought and had it flag that this contradicts the ICP it has on file, that's closer to a different decision than a convenience. Not sure yet how often that actually changes what gets built versus just what gets discussed.
That ICP contradiction use case is interesting. I’d be curious to see how often it actually changes decisions. If you’re open to it, what’s the best email to reach you on?
Addendum since a few people asked what actually makes this different: the memory part is just plumbing. The main thing Pythe does is generate the staged roadmap and push back like a cofounder would ("this isn't worth building yet, do X first") - the fact that it retains context between sessions is what lets it do that well, not the feature itself. Should have led with that.