The disabled feature list belongs in the adoption review
Training can succeed while the intended agent workflow remains unavailable. Track the permissions and acceptance conditions needed to make that workflow usable.
I would put the disabled feature list beside the training dashboard. Otherwise a team can finish the course and still be unable to perform the workflow the course promised.
Paul Baier’s August 2 field note describes seven Wall Street firms where Claude-focused training coexists with restrictions on agent features. It is a consultant’s small, self-reported sample, not a representative adoption survey. The precise training denominator is unclear, and the note does not establish how long each restriction will last.
The tension is still useful. Learning to use a capability and being permitted to use it in a particular environment are different conditions. A rollout plan should show both.
Make the blocked work visible
Imagine a hypothetical team trained to produce a weekly research brief from approved internal documents. In the training environment, the assistant can retrieve those documents. In the production environment, the connector is disabled pending review.
The participants may understand the workflow perfectly. Their low production usage would not prove a training failure or resistance to change. The missing dependency is access, and another generic prompting session will not restore it.
I would record the intended workflow, the unavailable capability, the reason for the restriction and the person who can decide what happens next. Then specify the evidence needed for that decision. If there is no approved route to enabling the capability, change the rollout promise rather than leave employees waiting for an unspecified future.
The evidence might be a narrower permission design, a satisfactory test of data handling or a version that removes an unwanted action. The appropriate requirement depends on the actual concern. “Security sign-off” is too broad to guide the team doing the work.
Re-enablement is a decision, not a target to maximise
A shorter disable list is not automatically progress. Some capabilities may be unnecessary or unsuitable for the organisation. Pressure to improve an adoption percentage should not turn every restriction into an obstacle that must be removed.
My proposed review would distinguish three outcomes: enabled for the intended workflow, available in a narrower form, or deliberately excluded. An exclusion with a clear rationale can be a completed decision. An indefinite hold with no owner or acceptance condition is unfinished work.
After a capability becomes available, check whether the workflow is actually used and whether its outputs are accepted. Permission is an enabling condition, not the outcome itself. That keeps the access review from becoming another proxy dashboard celebrated in place of useful work.
The Anthropic evaluation-incident disclosure provides context for serious scrutiny of agent environments. It does not prove that the firms in the field note made any particular restriction because of that disclosure, or that disabling an entire product is the only sensible response.
This is an operating proposal, not a report of my own work with those firms. I would use their reported tension to improve the questions in a rollout review, while resisting the temptation to generalise seven observations into a timetable for every enterprise.
The practical change is small. Before booking another training session, inspect whether participants can perform the approved workflow with the configuration they actually have. If they cannot, identify the decision that would change that state.
Measure adoption through usable workflows: show what is enabled, what is intentionally excluded and what evidence will resolve the remaining holds.
