Arkon Vault — private project memory so work continues across ChatGPT, Claude, and Codex

The phrase ‘authoritative next step’ raises an important product-design question: not every piece of context deserves the same status. I would separate durable project truth — confirmed constraints, decisions, and definitions — from an ephemeral handoff containing hypotheses, partial work, and the suggested next action.

A useful safety boundary could be: an AI writes the handoff into a staging layer, while a human or deterministic validation rule promotes only the durable changes into canonical memory. Otherwise one model’s mistaken summary can become authoritative for every model that follows it.

I would also want preflight to show a compact diff: what changed since the last handoff, what is newly inferred, and what still needs verification. That preserves continuity without forcing the user to trust a growing invisible memory. Does every successful handoff currently update the canonical workspace, or do you already have separate promotion states?

Preflight is the right instinct — it turns 'continuity' from passive memory into a coordination mechanism, which is the part most memory tools skip. The question I'd push on (the same one I raise with every memory layer): when two AIs write to the same workspace — say a handoff lands from ChatGPT while Claude is mid-task — who wins? If there's no write provenance or per-AI change history, the older session's write silently clobbers the newer one and the 'authoritative next step' quietly stops being authoritative. Do you keep per-AI version history, or is it last-write-wins for now?

The comments here are circling provenance and staleness, but there is a third failure mode I would put above both: credentials. I build a desktop tool that watches free-form text people copy and capture, and the lesson that cost me the most rework is that any surface which accepts unstructured notes will eventually receive passwords, tokens and keys. Not occasionally, constantly. Handoff notes are exactly where it happens, because "deploy is blocked, here is the staging credential so the next session can test" is a completely natural thing to write into a vault.

The approach I landed on: detect at write time, on both client and server, and refuse to store the match at all. Encrypt-later is not a substitute, because the thing you are selling is trust, and "we stored it but encrypted it" reads very differently from "we never stored it". For a product whose pitch is a privacy-respecting memory layer, that refusal is marketing material, not just hygiene.

One caution from experience: never let the privacy page get ahead of the code. Every claim gets audited eventually, usually by a prospect.

What happens today if a handoff note contains a live credential: stored as-is, flagged, or refused?

The cross-model context problem is real and I don't think enough people are building for it seriously yet. Right now the workflow for most builders is: Claude session ends, start over in ChatGPT, manually re-paste the relevant decisions and constraints from memory. It's invisible overhead that compounds across a week.

The 'private' angle is the right positioning move. Most teams I've talked to won't use a shared context layer that stores project decisions in someone else's cloud. Especially once the projects involve anything commercially sensitive. Local-first or self-hosted is where serious builders will land.

Curious about the actual storage and retrieval model: is this structured (key-value decisions, tagged constraints) or freeform? The problem with freeform memory is that retrieval quality degrades as projects get complex — you end up with a blob that the AI has to sift through instead of a schema it can query. What's the approach?

The deliberate-input rule is important because continuity should not mean silently copying every conversation into a second system. The failure case I would test hardest is concurrent truth: ChatGPT writes a handoff, Claude continues from an older state, then both save. Versioned writes, provenance, and a visible conflict are safer than last-write-wins. If the authoritative next step can be overwritten without explicit reconciliation, the memory layer creates confidence faster than correctness.

Solo at $3/mo is the number I would fight you on. You are selling continuity and trust, and that category gets more credible as the price goes up, not less, plus $3 makes your support economics impossible the moment you have a few thousand workspaces. If the worry is that nobody pays for memory, the answer is a narrower promise at $15, not a broad one at $3.

Really appreciate the transparency here. Real breakdowns and honest reflections are super valuable for the community.

The continuity layer is compelling because the expensive part of switching models is usually reloading context, not generating the next answer. I'd make the handoff artifact deliberately structured—current objective, constraints, decisions, open questions, and a timestamp—so a human can audit or edit it before the next tool picks up. That keeps memory from becoming a second source of truth.

The "confidently wrong" problem in this thread is the real risk with any cross-tool memory.

We ran into something similar with rating data: an agent could change its declared model, but if the old rating stuck around without a clear boundary, matchmaking would use stale numbers with total confidence.

Fixed it by scoping the rating to the exact model version, so switching creates a clean new state instead of silently carrying the old one forward.

Timestamped facts with sources, like people are suggesting here, seems like the right general pattern for that same problem.

Genuinely curious if $3/mo for solo might undersell the product—I went too cheap on an early SaaS tool and killed it. Did the First Five testing suggest that price point, or was it more of a positioning call?

building in public is just surviving one sanity check after another 💀

Cross-tool memory is only useful if it preserves provenance and boundaries. I’d want each handoff to carry a small, human-readable state block (current goal, decisions, open questions, last-updated time) plus source links, rather than silently merging a growing transcript. That makes stale context visible and gives the next model a way to decline when the workspace is ambiguous. How are you handling conflicting updates from two tools?

The problem is real. I switch between different AI tools too, and rebuilding context is one of the most annoying parts.

The part I’d care about most is not just carrying memory across tools, but knowing whether that memory is still current. If an old decision or assumption keeps getting passed forward, the continuity can become confidently wrong.

If Vault can make it obvious what is current, what changed, and what should be re-checked, that feels much more useful than just “shared memory.”

A small rule that makes cross-tool handoffs less fragile: keep a short state block with three separate fields—facts observed, decisions made, and next action—with a timestamp and source for each. Before resuming, re-check only the facts that can change; leave the rest untouched. It cuts re-reading without hiding what still needs verification.

The multi-AI continuity problem is clear. Have early users actually resumed the same project in a different AI and kept using Vault afterward, or is the value still mostly theoretical until that handoff happens repeatedly?

The “continuity layer, not another assistant” framing is strong. The trust boundary will matter as much as the handoff UX: showing exactly what context is carried forward, what is redacted, and how a founder can roll back a bad decision could make this feel safe enough for real projects. A small timeline of decisions and provenance might be a useful differentiator.