Two different changes
Learning that a supplier requires more lead time changes the context for future work. Raising a spending limit changes what actions are allowed. The first does not authorize the second.
Both can be useful changes, but they need different controls and different evidence.
What the current product supports
thinqOS supports proposals for configuration changes and a configurable continuous-improvement policy. Depending on that policy, changes can require review or a narrow allowlist of low-risk fields can be applied automatically. Outcomes are recorded in Learning history.
This is more precise than saying every change always waits for a human. Review the actual policy and allowed fields for the agent you deploy.
Two things sit outside that policy regardless of its settings. An agent cannot author an entirely new skill for itself from scratch and have it take effect without review. And there is no autonomous loop in which an agent grades its own performance and rewrites its own behavior based on that self-assessment. These are not settings to enable if you want them; the product has no path to either one today.
Test the consequential boundary
Use a harmless test to check what an agent can do without you, what stops for review and what is refused. Keep messages, purchases or other commitments manual where the required enforcement has not been demonstrated.
An instruction to ask first is useful guidance. It is not evidence that every tool call is mechanically gated.
Correct the learning too
A lesson can be wrong without changing any configuration. Inspect its source, correct it and test the next comparable task. Important confirmed material should not be silently displaced by a weak guess.
A governed agent needs both kinds of control: how its understanding evolves and how its authority changes.