We learned a different flavor of this when we took date formatting away from the model. It had been rendering dates and times for users, and doing it badly. A scheduling agent can't handle or render time with any inaccuracy, it undermines the whole experience. So we moved that job into our own code, where we could control it. But it had a consequence we didn't see coming.
With formatting handled elsewhere, the model now only saw raw UTC timestamps. As it did not need to reason about them to show the user, it no longer "saw" what the user did. The localized, human-shaped version "Thursday at 11am" was invisible. So when a user said "Thursday at eleven," the model had to map that phrase onto one of the UTC strings in the list we'd handed it. Making that jump was very unreliable. In resolving one problem, we'd increased the amount of reasoning needed in an adjacent area.
If it had simply been getting the time zone math wrong, we'd have seen a consistent offset, e.g. errors would be consistently out by an hour. But we didn't. It would pick the wrong day, or a time several hours adrift, with no pattern we could see. To all intents and purposes it looked like it was guessing. When faced with a list of opaque timestamps and a human phrase that didn't visibly correspond to any of them, it pattern-matched, badly. The same kind of failure as the 9am meeting, but in a more subtle guise.
The fix was the same move as before, made symmetric. Our tool result already required a time zone. For each available slot, it now returns both the UTC string the model must submit and a locally formatted label that matches what a human would actually say. The model sees the value it needs to use right next to the value close to what a person is likely to say. It no longer has to bridge the two in its head, we've joined the dots and reduced the reasoning required.
The first example was about not making the model compute. This one is about not making it translate between the form a machine acts on and the form a human speaks. Same root cause underneath: a gap between the shape of the data and the shape the model needs, which we always start from hoping it would close on its own.