Story How it works Tests Insights Whitepaper What's next Download Author Contact
← Back to Insights
Reflection

The stabilization weeks: making EIDARA boring to use.

Published June 30, 2026

From building to sharpening

Once a system does the thing it was built to do, the work changes. There is less building and more sharpening. The question stops being “what should it also do?” and becomes “where does it still surprise me, and why?”

That’s where EIDARA has been for the last couple of weeks. The senses work, the memory compiles, and the AIs maintain it together. Most days it just runs. But a self-maintaining system in real use keeps surfacing small surprises, and each one is a choice between patching it and fixing it properly. I’ve chosen to fix it properly every time.

Five kinds of crack that daily use exposes

A few things show up over and over once you run the system for real, every day, with real data:

  • A counter that looks like it limits something but doesn’t.
  • A piece of internal state that drifts out of sync with reality without anyone noticing.
  • A summary that becomes wrong because the world around it shifted, not the file it lives in.
  • A maintenance pass that was supposed to run and skipped silently, without raising a hand.
  • A hundred small reasonable decisions that, added together, drift somewhere they shouldn’t.

None of these are dramatic bugs. They’re cracks in the safety net, the part of a system that only acts when something else goes wrong. Because it almost never runs, it almost never gets watched. Finding those cracks is the reason to run the system for real.

Fix it properly, not patch it

The temptation is always to patch: add a special case, raise a threshold, restart a thing. I’ve been resisting that hard. For each issue the question is the same: what structural change means this whole class of problem can’t happen again?

That’s slower than patching, and the fixes look smaller on the surface while going deeper. A hard limit replaces a soft one. A check against external reality replaces trust in internal bookkeeping. A verification that maintenance actually ran replaces the assumption that it did. Most of what shipped these weeks is an existing capability that now fails predictably when it can’t do its job, instead of pretending it succeeded or trying the same impossible thing forever.

Should the background curator switch models?

I also took the time to ask whether EIDARA should swap the local model it uses for its background curator. There are interesting new options out there, so I compared them properly on latency, memory footprint, reliability of structured output and multilingual quality.

The answer was the boring one. The local model I’m already on is still the right balance for this hardware and this workload. The newer options are competitive, but none improves things enough to justify the switching cost right now, so I’ll re-evaluate when one does. Being able to make that decision calmly is a good sign: it means the rest of the system is solid enough that a model upgrade would be an optimization, not a rescue.

Stabilization isn’t finished yet

I’m not done. Stabilization ends when you stop being surprised, and I still get surprised, just less than before. The difference from a few weeks ago is not speed or new features. When something breaks now, it breaks in a way I can see and contain, and the work is becoming predictable and recoverable.

The sign this phase is over will be a week of daily use with no new surprise. I’m not there yet, but the gaps between them are getting longer.

Javier

A memory that maintains itself has to fail visibly. That’s the bar for SUPER DARA.


See the full roadmap →

Keep reading

Upgrades from a fresh audit of EIDARA Why my AI doesn't have eyes