The interview stops guessing what the platform can do
The interview is where people ask whether the platform can do something. It was answering from three sources, none of which was the product: its own frozen instructions, its training data, and inference. An audit read those instructions against the shipped code and found seven places where they had drifted. Four were still live. One of them had the agent telling owners there was no browser, on a platform where the browser is always on.
Both directions of that cost something. A wrong yes has you designing a workflow around a capability that does not exist, and finding out at publish. A wrong no is worse because it is invisible: the agent refuses something that shipped, nothing errors, nobody files a bug, and you simply believe the product cannot do it.
The agent now carries the platform's own capability documentation and has to consult it before making a claim about what the platform can do. Broad questions start from a bundled overview; specific ones and "did that ship" questions go to the live documentation site. That overview is also the one home for what the platform deliberately does not do, dated, because a confident no needs a source as much as a confident yes does.
It also has to say so when a lookup failed and flag what it is falling back on as possibly stale, and to answer "I do not know" rather than reasoning its way to something plausible. When the answer matters to your workflow, it records it as an open question instead of quietly picking one.
This entry describes what shipped on the day it shipped. For how the capability behaves now, read /docs/workflows.