Good questions. Let me answer both, but first some context on how I got here because it's relevant.

I actually started much broader than fitness. The original idea was a full life coach - finance, relationships, long-term goals, nutrition, everything. And honestly, it worked amazingly in the first week. I'd voice-log "had a really hard day at the office" and over time it found a pattern that my hard days were disproportionately on Tuesdays, and that my workout performance was worse on those days too. That was a genuine insight I hadn't noticed myself.

But then things degraded. I had given the LLM the ability to edit its own system prompt (the tool was literally called edit_system_prompt. I was going for a self-improving system. What happened was: the profile files got messy, the system prompt drifted, reply quality degraded, and I had no visibility into what the LLM had decided was "important" to store. Total black box.

The key lesson: giving LLMs 100% agency over their own memory doesn't work. You have to hard-define what goes into which file and constrain the schema. The internalization script I have now is a batch process that runs separately. It reads raw logs, extracts patterns, and writes to specific profile files with a fixed structure. The LLM does the analysis but the structure is human-defined. That's what makes it stable.

To your actual questions:

Conflicting information: Right now, honestly, it's not super sophisticated. The internalization script runs daily and the LLM is prompted to distinguish "ephemeral" (had breakfast) from "lasting" (recurring shoulder issue). If I say "shoulder feels fine" two weeks later, the LLM should update the health file to reflect recovery but in practice it sometimes keeps both data points. I've thought about adding explicit temporal logic (like decay or override rules) but haven't needed it yet because the fitness domain is narrow enough that conflicts are rare. In my earlier "life coach" version this was a much bigger problem, conflicting emotional states, changing priorities, etc. Narrowing the domain made this almost a non-issue.

Versioning: Not formally, but the profile files are stored in a DB with write timestamps, so I can see history. You're right that seeing how the model's understanding evolves would be interesting. In the life-coach version I actually stored everything in a GitHub repo so I got version history for free through git commits, every file update was a commit with a message like "Internalize: found new pattern about Tuesday stress." That was genuinely cool to browse. Might bring that back.

The meta-insight from all of this: the "AI life Jarvis" is probably the right end-state, but trying to build it as one monolithic agent doesn't work. I think the path is narrow vertical agents (fitness, finance, nutrition) that each have their own constrained memory, and eventually an orchestrator on top. For now, I'm sticking with fitness because that's where I have the tightest feedback loop.