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

A different kind of work

Once a system does the thing it was built to do, you enter a different kind of work. Less building, more sharpening. Less “what should it also do?” and more “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, the AIs maintain it together. Most days it just runs. But a self-maintaining system in real use surfaces small surprises constantly — and each one is an invitation to either patch it or fix it properly. We’ve been choosing fix it properly every time.

What real use surfaces

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 quietly 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 quietly skipped 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, and so almost never runs and almost never gets watched. Finding them is the whole point of running it for real.

Fix it properly, not patch it

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

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

The model question

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

The conclusion was the boring one: the local model we’re already on is still the right balance for this hardware and this workload. The newer options are competitive, but none are transformational enough to justify the switching cost right now — so we’ll re-evaluate when something actually moves the needle. That’s a good kind of decision to be able to make calmly. It means the rest of the system is solid enough that a model upgrade would be optimization, not rescue.

Where this lands

We’re not done — stabilization ends when you stop being surprised, and we still get surprised, just less than before. But what’s different from a few weeks ago isn’t that the system is faster or can do more. It’s that when something breaks, it breaks in a way I can see and contain. The work is becoming boring in the best sense of the word: predictable, recoverable, mine.

Every week it gets a little closer to the thing I want it to be.

— Javier

EIDARA v2 is free. SUPER DARA is what comes next.


See the full roadmap →

Keep reading

I gave my AI three senses The day my system stopped crying wolf