One of the least glamorous problems in building our AI tools has been configuration drift. A service works on Monday, then a package update, a changed setting or a new deployment means the same command no longer produces the same result.

A concrete example of the failure pattern: an assistant helps configure a model runner and a web interface. Later another assistant adjusts a setting to fix a different problem. The original setup instructions no longer describe the running system. A restart exposes the mismatch. Without a saved baseline, the team wastes time reconstructing what changed.

Our Foundry work also showed that passing tests does not guarantee the overall operator experience is useful. A component can be technically present while a practical workflow remains broken. We had to reject work and return to simpler arrangements. That is a project lesson, not evidence that one specific lost configuration caused every failure.

What would we do differently? Save a known-good configuration before changes; record the software version and the reason for each edit; change one thing at a time; test a restart; keep a rollback copy; and verify the actual user workflow, not just a green test report.