From Copilot to Agent: Product Evolution Path

Key facts, with sources

• Gartner predicts over 40 percent of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. (Gartner)
• Gartner predicts 33 percent of enterprise software applications will include agentic AI by 2028, up from less than 1 percent in 2024. (Gartner)
• Gartner estimates only about 130 of the thousands of vendors claiming to sell agentic AI are real, with the rest engaged in agent washing of existing chatbots and RPA products. (MarTech)
• McKinsey's State of AI 2025 found 23 percent of organizations are scaling an agentic AI system somewhere in the enterprise and another 39 percent have begun experimenting with agents. (McKinsey)
• Gartner forecasts 40 percent of enterprise applications will embed task-specific AI agents by the end of 2026, up from under 5 percent in 2025. (Joget)

The autonomy ladder

I think about copilot-to-agent as five rungs. Suggest: the system proposes, the human does. Draft: the system produces the artifact, the human edits and executes. Act with approval: the system is ready to execute and waits for a yes. Act with notification: it executes and tells the human, who can undo. Autonomous: it executes silently and reports in aggregate. Each rung transfers a bit more of the execution burden and requires a bit more trust — and, critically, each rung generates the evidence for the next.

Most products should live on different rungs for different actions simultaneously. "How autonomous is your agent" is the wrong question; the right one is which actions sit on which rung, and what evidence moves them.

Your copilot is a data collection instrument

A copilot with telemetry is running a continuous experiment on where autonomy is safe. Log every suggestion and draft with its action type, whether the user accepted, edited, or discarded it, and how much they edited. After a quarter you have a ranked list: action types with very high untouched-acceptance are automation candidates; heavily edited ones need better context or tighter scope; frequently discarded ones are not ready and might never be.

This instrumentation has to be designed in, not bolted on — "accepted" needs a real definition in the UI (used verbatim? sent within a minute?), and edits need diffing. Teams that skip this end up guessing which actions to automate, which is exactly the decision the copilot phase should have answered with data.

Approvals are the bridge rung

Act-with-approval is the load-bearing rung, and products fumble it by treating approval as a yes/no dialog. Done well, the approval moment shows the full consequence (the exact email, the exact refund), offers an edit path, and records the decision with enough context to learn from. Rejections deserve special attention: a one-tap reason — wrong tone, wrong recipient, bad timing — turns every no into training signal for prompts and context.

Approval fatigue is real and informative in both directions. If users approve nearly every request for an action for weeks, the gate has become friction — promote it. If they keep rejecting, the agent is not ready — demote it to drafting and study the rejection reasons. The gate is a measurement device, not just a safety device.

Promote per action and per customer

Autonomy should be promoted per action and per customer, not as a product-wide mode. A given customer's data quality, workflow, and risk tolerance determine whether auto-filing the ticket is safe for them specifically — and your acceptance telemetry is per-customer already. I model it as a permission matrix: action types on one axis, autonomy rung on the other, defaults set by your global data, overridable per customer, with promotions suggested automatically when their acceptance history clears a threshold.

This converts the scary relaunch — "we are an agent now" — into a stream of small, reversible changes. It also gives enterprise buyers exactly what they want: a control panel over what the system may do on its own, with their own usage data justifying every setting.

The product and pricing shift

The rung shift changes the product surface. Copilot UX is assistance: inline suggestions, side panels, drafts in the editor. Agent UX is supervision: queues of completed work to review, receipts, exception handling, and controls to adjust autonomy. Teams often underinvest in the supervision surface because the copilot UI already exists — but a user managing an agent needs fundamentally different affordances than one accepting suggestions.

Pricing usually shifts a rung behind the product. Seats price assistance well; once the system executes work, per-task or per-outcome pricing captures the value better and scales with what the customer actually receives. The transition point shows up in the data when usage decouples from human headcount — when work volume no longer tracks the number of people logged in, seat pricing is leaving money on the table.

What must be true before full autonomy

Before any action goes fully autonomous, I want five things true: a measured acceptance rate at the approval rung high enough that the gate is pure friction; an undo or compensation path for the action, tested; runtime budgets and anomaly detection that halt the agent when behavior shifts; an audit trail complete enough to reconstruct any run; and a kill switch a human can hit without engineering help. The list is short, but each item has real engineering behind it.

Autonomy is also never final. Model upgrades, prompt changes, and drift in customer data can all degrade a previously safe action, so the acceptance monitoring that justified the promotion keeps running afterward — auto-executed actions get sampled for review, and a quality drop demotes the action back down the ladder automatically. The ladder goes both ways, and products that only climb eventually fall.

When to hire senior help

Senior help is most valuable at the architecture stage, deciding what to automate, where approval gates belong, and how business value will be measured, before any code is written. It is also worth bringing in when a stalled pilot needs risk controls and evaluation rigor to pass security and compliance review. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — Agentic AI Systems projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Buying agent-washed products, since Gartner estimates only around 130 of thousands of self-described agentic AI vendors are genuine rather than rebranded chatbots or RPA
• ✕Deploying autonomy before defining risk controls and human-approval gates, one of the three causes Gartner cites for the 40 percent of projects it expects to be canceled
• ✕Measuring activity like tasks attempted instead of business value, leaving the project unable to justify escalating costs at renewal time
• ✕Wrapping agents around existing processes instead of redesigning the workflow, when McKinsey finds workflow redesign is the single biggest driver of EBIT impact from gen AI

Frequently asked questions

Sources

• Gartner
• MarTech
• McKinsey
• Joget