10decoders
The Agent Finished in Nine Seconds. The Ticket Closed in Three Days.
Take an invoice exception workflow in a finance GCC. An agent reads the invoice, matches it to the purchase order, spots a quantity mismatch, drafts the resolution, and posts it for review, all in under ten seconds. The reviewer sees it the next morning because the queue is shared with six other teams. A team lead approves it that afternoon because policy requires a second signature above a threshold. The vendor hears back on day three. The agent cost a few cents, and the two signatures cost two days.
This pattern is common because of how GCCs adopt agents. A pilot is built inside an existing process, and the existing process has approvals, handoffs, and sign-off thresholds that were designed for human error rates and human throughput. Nobody wants to be the person who removed a control, so the agent is added as a faster first draft. The workflow shape stays the same: linear, approval-gated, and sized for a person at each step.
EY describes the alternative in its March 2026 piece on agentic AI GCCs: workflows move from linear approvals to event-driven environments where agents execute and escalate only exceptions. That is a redesign of the process, and it is a harder conversation than adopting a tool. It means deciding which approvals exist because of a real failure and which exist because the process always had them. It means a risk owner agrees in writing that a class of actions no longer needs a person. GCCs are well placed to have that conversation, since they hold the process knowledge, the engineering capacity, and the governance staff in one organization, but they have to choose to have it.
An agent that waits for a human click has the throughput of a human.
Six Places Agentic Workflows Stall Inside a GCC
These are the stall points we look for first when a GCC tells us its agents are live but cycle time has not moved. Severity reflects how much elapsed time and rework each one adds to a typical workflow.
| Stall point | What happens | Severity |
|---|---|---|
| Approval chain copied from the manual process | Two or three sign-offs designed for human error rates remain in place, so the agent's speed is absorbed by queue time | Critical |
| No explicit exception policy | Nobody has defined what the agent may finish alone, so everything escalates and reviewers see volume instead of edge cases | Critical |
| Escalations without context | Reviewers receive a conclusion and must rebuild the evidence across several systems, which adds minutes per case and lowers review quality | High |
| Rubber-stamp review | Approval rates approach 100% and review time per item falls, so the control exists on paper and catches little | High |
| Ownership split across the parent and the GCC | The GCC runs the agent while a business unit at headquarters owns the policy, so changing a threshold takes a quarter | Moderate |
| Metrics that count agent tasks, not outcomes | Dashboards report tasks automated while end-to-end cycle time and rework stay flat, so the stall stays invisible | Lower |
Not sure where your agentic workflow gaps are?
10decoders maps one live GCC workflow end to end, marks every approval and handoff, and shows where elapsed time actually goes. You get a ranked list of steps to remove, sample, or keep.
Book a Free AI Assessment →How to Decide Which Approvals Stay
The useful question for each approval is what failure it was added to prevent. Some answers are strong: a payment above a legal threshold needs two people, and a change to a regulated record needs a named approver. Other answers are weak: the step was added after one bad month three years ago, or the reviewer only checks that a field is filled in. A field check is something software does better than a person, and moving it into the agent's own validation removes a queue without removing a control.
For approvals that remain, change the shape of the review. A person who must confirm every action will approve quickly and read little. A person who sees only the cases the agent flagged as uncertain, with the evidence next to the proposal, will read carefully because each case is unusual. This is the practical meaning of exception handling. The reviewer's workload drops, and the quality of each review goes up.
Regulation sets the outer limits and it is moving. India's Digital Personal Data Protection Rules, notified in November 2025, bring compliance obligations that take effect by May 2027, and the February 2026 India AI Governance Guidelines point to human oversight and accountability. Those requirements do not say every action needs a human click. They say someone must be accountable and able to intervene, which a well designed exception policy with caps, sampling, and rollback can show.
Same Workflow, Quicker First Step
The agent produces a draft and every output goes to a person. Elapsed time barely moves, and savings show up only as saved typing.
Low-Risk Cases Skip the Queue
A written policy lets the agent finish defined cases alone, with caps. Humans review flagged cases, though reviewers still lack a standard evidence view.
People Handle Exceptions and Policy
Agents act on events, humans see only escalations with evidence, sampling audits the rest, and cycle time is tracked end to end.
Checklist: Is Your Workflow Built for Exceptions?
Pick one workflow where an agent is already live. For each item, ask whether you can show it, not whether someone believes it is true.
The goal is not fewer people in the process. It is people spending their time where judgment changes the outcome.
What to do this week
01 Time one workflow from request to outcome
Choose the busiest workflow where an agent is already live and trace twenty recent cases from the moment the request arrived to the moment the outcome reached the customer or the system of record. Record active time and waiting time separately for each step. Most teams find that waiting time between steps is several times the active time. That single chart is the argument for the rest of the work, and it is hard to dispute because it comes from real cases.
02 List every approval and write down why it exists
For each human sign-off in that workflow, write the error it was added to catch, the last time it caught one, and who owns the rule. Mark each as keep, replace with automated validation, or move to sampling. Bring the risk owner into this session and not after it, since the output needs their agreement. Expect a few approvals to have no recorded reason, and treat those as the first candidates.
03 Draft the exception policy for one action class
Pick one narrow class, such as invoice mismatches under a set value, and write three lists: what the agent completes alone, what it escalates, and what it must never do. Add a value cap per action and per day, plus a trigger that sends any case with low confidence or missing data to a person. Keep it to one page. A policy short enough to be read and tested beats a thorough one that sits in a folder.
04 Build the reviewer view and start sampling
Give reviewers one screen showing the inputs, the tool calls, the proposed action, and the reason for escalation. Run the new policy in shadow mode for two weeks, where the agent decides and the old approval still happens, then compare outcomes. If agreement is high, move the low-risk class to sampled audit and track override and reversal rates weekly. Keep the old path available for a rollback until the numbers have stayed stable for a full month.
Let 10decoders Redesign the Workflow Around Your GCC Agents
We time one live workflow end to end, catalog every approval and handoff, draft the exception policy with your risk owner, and design the reviewer view. You leave with a ranked list of steps to remove, sample, or keep, and a shadow-mode plan you can run in two weeks.