This week I shipped something that made careercraft.ing feel much more like a real MCP App.
Until now, the memory flow was functional, but still a bit too tool-shaped.
You could create a memory.
You could save it.
But the experience around that step was not yet good enough.
So in Week 5 I focused on turning that into a proper preview flow thanks for the MCP Apps integration.
Now the app can generate a memory preview, render it in a custom UI, show suggested tags, and let the user explicitly decide whether to save it.
That sounds like a UX improvement.
It is. But it also changed the product boundary in an important way.
I do not want memory capture to feel like:
"send text in, hope the server did something sensible, check later."
I want it to feel like:
"here is the draft, here is what the system understood, now confirm it."
Under the hood, that meant:
a KV-backed preview/save flow
a custom MCP App UI for previewing memories
cleaner loading and error states
tighter workflow documentation
a better separation between preview generation and final persistence
And almost immediately after that, another issue became obvious:
once the UX gets better, the data path underneath it has to be tighter too.
So the current follow-up PR is focused on reliability:
reducing memory lookup and hydration query fanout
hardening tag creation/sync to avoid duplicate or race-prone associations
improving fallback behavior when the preview app is not available
That second part is less visible, but probably just as important.
A polished preview is nice.
A preview that saves the wrong thing, duplicates tags, or makes too many DB calls is not.
I like this kind of week because it feels honest:
not a huge launch, not growth theater, ljust turning a promising interaction into something more trustworthy.
Next step is to finish the optimization pass, keep tightening the memory workflow, and make the whole loop feel fast enough that you would actually want to use it repeatedly.
https://youtu.be/QCV0OMlLfdw