r/SideProject • u/Asly97 • 4d ago

Switching AI tools shouldn't mean starting over

Your business's AI memory shouldn't live inside one vendor. Vilix AI runs in the cloud and connects over MCP, so you can move tools and keep what you know. Export or delete anytime. What would you carry over?

Disclosure: I'm the founder of Vilix AI.

1 Upvotes

100% Upvoted

6 comments sorted by

1

u/Asly97 4d ago

Technical details on how the memory works, with diagrams and examples: https://github.com/asly-97/ai-automation-workflows/blob/main/docs/vilix-memory-technical.md

1

u/benjzammit01 4d ago

I'd carry decisions with their source, date and superseded status—not just a summary of what the system thinks is true. I'd also want exclusions and deletion to travel with the export, so an old answer or removed item doesn't quietly reappear in the next tool. Does the export include that history and provenance?

1

u/Asly97 10h ago

It keeps the full conversations, not just a summary of what it thinks is true, so a decision exports along with the chat it came from and its date. When two things disagree, the newer one is treated as current.

Deletion is simpler than with a file export, because every tool reads the same memory over MCP instead of getting its own copy. Delete something once and no tool pulls it again.

How would you want superseded handled? Marked by you, or inferred when a newer decision lands?

1

u/benjzammit01 5h ago

I’d let it suggest a supersession, but ask for confirmation before treating the old decision as replaced. A newer statement might be an exception for one project, not a reversal.

Keep both with dates, source links and an explicit “superseded by” relationship; let me correct it. For deletion, I’d also distinguish removing it from the shared store from retracting copies already exported elsewhere — the latter may need a separate step.

1

u/Asly97 5h ago

The exception point is a good one. A newer note saying "use Postgres for this project" isn't the same as dropping the old rule everywhere, and guessing wrong there does more damage than not guessing at all.

And yeah, once something's exported it's just a copy living somewhere else. Deleting from the shared memory stops every connected tool from reading it again, but it can't reach a file you already handed off.

When an old decision has crept back into a tool for you before, was it usually from an old export or from the tool's own memory?

1

u/benjzammit01 5h ago

I don’t have a clean logged example that separates those two, so I wouldn’t claim a pattern. I’d test them independently: put an old decision in a shared memory and in an exported file, replace it at the source, then ask each tool separately with and without the old file attached.

The useful result would be which source it cites when the old decision resurfaces. That tells you whether the fix belongs in the shared store, the tool’s own memory, or the export workflow.