An agent-adoption curve should be a coaching tool, not a leaderboard

Salesforce's 9 September account of its internal engineering pilot describes a maturity curve from direct question answering through task delegation to coordinated agents. As a shared vocabulary, that can be useful. Teams need language for discussing how much context, tool access and execution authority a workflow has. The danger begins when the curve becomes a target for ranking people or teams.

My view is that an adoption curve should guide coaching and control design, not reward movement toward the most autonomous label. Higher autonomy is not automatically better work. The appropriate level depends on consequence, evidence quality, repeatability, recovery cost and the rights of the people affected by the decision.

Maturity is not maximum autonomy

A formula that calculates days to renewal may be more mature than an agent that guesses urgency from scattered notes. A deterministic routing rule may be preferable to a model even if it sits lower on an autonomy diagram. The right system is the smallest one that can complete the decision reliably and leave an inspectable record.

Teams should describe maturity in terms of operating capability: source evidence is defined, outputs are structured, permissions are bounded, exceptions are owned, costs are visible, versions are retained and outcomes are verified. Those controls can improve at every autonomy level. A chat assistant can be poorly governed; a multi-step agent can be well governed; neither label answers the review question by itself.

Leaderboards distort the work

If managers celebrate the number of agents deployed or the percentage of work delegated, teams will search for automatable steps rather than consequential problems. They may split one workflow into many nominal agents, grant broader access to demonstrate sophistication or avoid reporting failures that would lower a maturity score. The metric begins to manage the narrative instead of the system.

A public ranking also makes abstention look weak. Yet an agent that stops when evidence is ambiguous may be safer and more useful than one that completes every task. Unknown, needs review and prohibited are valid outcomes. The operating design should reward correct boundaries, not confident completion.

Coach from one real workflow

Choose a recurring task and ask the operator to draw the source, interpretation, policy, approval, execution and verification steps. Identify which steps are deterministic and which require judgment. Then ask what evidence would allow more delegation and what failure would require less. This conversation reveals the next learning need without assigning a person a maturity rank.

Use peer review for context construction, tool selection, evaluation design and recovery planning. Ask one team to demonstrate a normal case and an exception. Let another operator reproduce the decision from the retained evidence. Coaching is successful when the workflow becomes easier to explain and repair, not when it acquires another model call.

Measure control and usefulness

Track accepted and rejected proposals, corrections, unsupported outputs, prohibited actions, exception age, duplicate work, downstream verification, operator time and cost. Keep the denominator tied to a defined eligible population. Include the customer or commercial consequence of material errors. Avoid a single composite score that allows many small successes to erase one severe failure.

Ask whether the workflow reduces unresolved work, improves the quality of a decision or releases capacity that is actually used. Those are local questions. Salesforce's reported internal experience can suggest what to inspect, but it does not establish a productivity target for another company, role or process.

Keep progression reversible

Before granting broader execution authority, prove that the team can pause the workflow, preserve pending cases, revoke credentials, identify affected records and restore a defensible state. Run that exercise. A slide describing rollback is not evidence that recovery works.

Progress can also move backward. A source schema changes, a model version behaves differently, a new regulation applies or the workflow enters a higher-consequence population. Returning to proposal-only mode is responsible change control, not failure. Record why the boundary changed and what evidence would justify revisiting it.

A better maturity conversation

Teams also need psychological safety around failure evidence. If an operator expects a blocked action or correction to damage their ranking, the organization loses the information required to improve the workflow. Review incidents at the level of the decision contract: which evidence, rule, permission or handoff failed, and what system change prevents recurrence. Do not turn a post-incident learning review into a contest over who used the most advanced tool.

Replace how advanced is this team with six questions: Is the decision defined? Is the evidence traceable? Is authority bounded? Are exceptions owned? Can cost and quality be measured? Can the action be reversed or reconciled? These questions keep the focus on work, not status.

A maturity curve earns its place when it helps a team choose the next safe experiment. It becomes harmful when it converts technological ambition into a performance proxy. Coach people to improve judgment, evidence and controls. Let autonomy remain a design choice rather than an organizational trophy.

Related: Decision contract for agents or rules · Salesforce tool profile