As enterprise AI transformation moves from point‑solution tooling to full‑scale workflow re‑architecture, Uber has executed a transformation across all functions—R&D, finance, operations, marketing, HR—powered by Agentic AI. Unlike most enterprises that limit AI to shallow uses like code assistance or single‑task automation, Uber has adopted a lightweight, highly agile, business‑anchored implementation model that elevates AI from a mere “tool” to the underlying logic of organisational operations. The metrics, team mechanisms, and core methodologies disclosed by CTO Praveen Neppalli not only demonstrate the digital evolution of the mobility giant, but also provide a replicable and scalable benchmark for large and mid‑sized enterprises worldwide.
After reading Praveen Neppalli’s retrospective[1] on Uber’s Agentic AI deployment, several dimensions merit deeper exploration. This is not a typical “AI efficiency hype” piece, but a remarkably candid disclosure of organisational change methodology—especially its admission that “what surprised us most wasn’t the speed, but the opportunities revealed through embedded observation.” That single point pinpoints the root cause of most AI transformation failures today.
Let us dissect it from three levels.
The Underestimated Core Proposition: The Unit of Automation is the Workflow, Not the Task
This is the most important assertion in the entire narrative: “The workflow becomes the unit of automation — not the individual task.”
For the past decade, enterprise automation has followed a path of “task automation”: RPA runs a reconciliation script, BI tools generate reports, chatbot handles FAQs. The hallmark of this approach is bottom‑up, point‑based, locally optimised—easy to calculate ROI per point, but with a low ceiling and often creating new “automation silos”.
Uber’s 16 Pods, in essence, undertake workflow re‑architecture. I abstract it into three progressive layers:
| Level | Objective | Typical Actions | Uber Case |
|---|---|---|---|
| L1 Task Automation | Save single‑step effort | Scripts, RPA, Copilot | Write a SQL query, generate copy |
| L2 Process Automation | Eliminate hand‑off steps | Tool chaining, state machines | Support ticket routing |
| L3 Workflow Re‑architecture | Redesign the way work is done | Remove hand‑offs, merge approvals, replace systems | Capital allocation 15h→30min means the entire chain was rewritten |
Note that capital allocation from 15 hours to 30 minutes is not a 30‑fold speed‑up of a single step, but a complete re‑engineering of the entire approval‑data‑simulation‑deployment pipeline. This implies that traditional “flowcharts” are obsolete—you cannot draw the future workflow because it is orchestrated autonomously by agents, not driven by humans step by step.
This is the most fundamental methodological watershed that distinguishes the LLM era from the previous wave of AI/RPA.
Agentic Pods: A New Organisational Atom
Even more intriguing is Uber’s organisational design. “~30 AI‑proficient engineers + domain experts, two weeks per Pod”—this is neither a project team, nor a Centre of Excellence (CoE), nor a product squad.
I would label it an “Embedded Strike Cell”. It has four distinct characteristics compared to traditional organisational forms:
1. Extremely tight time‑box. Two weeks, including shadowing, opportunity assessment, prototyping, cross‑sample validation, and shipping. Any impulse to “do more research” is physically cut off. This forces teams to compress “understanding the business” and “building” into the same timeframe—counter‑intuitive, but consistent with modern product development’s “iterate fast” logic: understanding is not a prerequisite; it is a by‑product of building.
2. Highly asymmetric pairing. One AI engineer paired with one domain expert. Note—not “one domain expert supported by multiple engineers”, but one‑to‑one. This implies a key insight: the domain expert’s time is the true bottleneck; engineers are relatively abundant. This is a fundamental inversion of the traditional “business writes requirements, IT implements” model.
3. Horizontal cross‑functional diffusion. 16 Pods run across 16 different functions (finance, legal, operations, marketing, support, HR, procurement…) in parallel. Uber did not choose to “nail it in finance first, then replicate”; instead, it uses parallel Pods to accelerate pattern validation. This is a classic “portfolio innovation” approach—tolerating some failures while maximising the chance of discovering truly high‑value scenarios.
4. Built “inside” the business, not “for” the business. The repeated phrasing is “alongside the person doing the job” and “with them, not for them.” This is not rhetoric; it is discipline—the debugging of agent prompts, tools, and boundary conditions happens in the presence of the actual business operator, not in a conference room.
The subtlety of this organisational atom is that it reduces “AI transformation” from a strategic programme to a set of schedulable operational events, thereby bypassing the biggest killer of most transformation initiatives—the long governance‑committee chain of “proposal‑review‑pilot‑rollout.”
What That Data Actually Tells Us
Let me reread the four signature numbers:
- Capital allocation (150 cities): 15h → 30min (–97%)
- Financial pacing reports: 2 days → 10min (–99%)
- Marketing web QA: 2 weeks → 50min (–99.97%)
- Support workflow creation: 9,000 manual → self‑service (∞)
These four use cases are not random; they cover four quadrants of the Agentic AI value spectrum:
- High‑frequency repetitive × structured data (capital allocation)—a classic “expert system” scenario, where the agent converts human judgment into parametric decisions.
- Cross‑system aggregation × time‑sensitive (pacing reports)—a classic “analytical orchestration” scenario, where the agent replaces mid‑layer analysts.
- Quality validation × fuzzy rules (marketing QA)—a classic “review” scenario, where the agent’s language understanding begins to replace human eyes and experience.
- Process configuration × long‑tail demands (support workflows)—a classic “empowerment” scenario, where the agent enables frontline business teams to self‑serve, emptying the traditional IT demand backlog.
Plot these four on a single map, and Uber in two months has validated the “coverage capability” of Agentic AI transformation—it is not a silver bullet for one type of work, but a full‑spectrum tool across decision‑making, execution, review, and empowerment. This conclusion is far more valuable for other enterprises than any single percentage.
Several Important Questions Not Addressed in Praveen’s Post, but Critical for Any CTO Evaluating a Similar Path
Praveen’s narrative is restrained, but I must point out a few things he did not mention—questions every CTO considering this path needs to ask:
1. Governance and compliance gaps. 16 Pods shipped 16 agents in two months, but no mention of permission boundaries, audit trails, or regulatory reporting standards. Capital allocation is especially sensitive—a global treasury agent that runs in 30 minutes: who gives final approval outside the loop? If speed bypasses “two‑person check” or “risk threshold reviews,” the tension between short‑term efficiency and medium/long‑term risk cannot be ignored.
2. Long‑term maintainability. 2,500+ agent skills sound exciting, but version management, dependency governance, and drift detection in production are a separate engineering discipline. “Can ship in two weeks” does not equal “can run stably for six months.” Uber’s retrospective does not mention this—perhaps because it is too early, or because it is the next hurdle.
3. The “reverse de‑skilling” risk for domain experts. When a finance expert delegates 80% of their work to an agent, their judgment, domain intuition, and ability to explain anomalies may decline. If the agent makes a mistake, the human cannot backstop—cases in finance and healthcare are already numerous. Uber’s “embedded observation” alleviates knowledge transfer, but does not solve knowledge retention.
4. Baseline selection for the numbers. 15 hours → 30 minutes sounds like a 30‑fold improvement, but how much of that baseline was internally redundant manual process? If the baseline was a workflow “designed to be slow to match approval cadence,” then the 30‑fold reflects process re‑engineering value, not necessarily AI value alone. This does not diminish Uber’s achievement, but readers should distinguish the two when interpreting.
Setting Aside Uber’s Uniqueness, Here Are Four Replicable Takeaways
First, bind “finding high‑value scenarios” and “building a working prototype” into the same activity. Stop asking business units to write requirement documents first and then have IT schedule two months for assessment—by then the window has closed.
Second, form “Embedded Strike Cells” instead of an “AI Centre of Excellence.” A CoE is a preacher; a Pod is an executor. The CoE delivers methodology, the Pod delivers business outcomes. Both are needed, but neither can replace the other.
Third, acknowledge that “flowcharts” are obsolete planning tools. When agents can autonomously orchestrate across multiple systems, a static flowchart can only describe the past, not constrain the future. Replace it with a triad of “decision points + tool permissions + boundary conditions.”
Fourth, make “workflow re‑architecture” the central narrative of change. Do not tell the CEO “AI improved efficiency by X%”; tell the CEO “we rewrote how the X process is organised.” The former is a one‑time gain; the latter is a structural advantage.
Closing Remarks
The last sentence in Praveen’s post[1] deserves to be highlighted: “We’re now forming a dedicated team to scale this further and go deeper.”
The tone is calm, but I read three layers: First, the 16 Pods are a methodological validation, not the finish line; second, they are transitioning from “commando mode” to “standing‑army mode”; third, Uber is betting that Agentic AI is not a project, but a new operating normal.
For other enterprises, the most dangerous signal is not “my engineers haven’t adopted Copilot yet,” but “my CFO still thinks his/her 2026 working style is the same as 2023.” The real shock of the Agentic Pods model lies not in its novelty, but in the fact it reveals: when AI can be embedded alongside business executors, the traditional “business‑IT” boundary is being permanently rewritten.
The core barrier to enterprise AI transformation has never been the introduction of technical tools, but the organisation’s ability to adapt to and reuse AI. Uber first achieved deep AI penetration in its R&D system, building a solid technical foundation for full‑business expansion. Official data shows that currently 99% of Uber’s engineers use AI tools on a regular basis, over 70% of pull requests are attributed to local or cloud agents, and the team has accumulated over 2,500 agent skills across the entire software lifecycle.
This high‑penetration data signals that Uber has completely shaken off the traditional “AI pilot‑and‑spot” model, achieving an AI‑native working paradigm for R&D roles. From an industry perspective, most enterprises have an AI tool adoption rate below 50%, mostly confined to basic code generation scenarios. Uber, through large‑scale skill accumulation, has embedded AI into the entire lifecycle—requirement iteration, coding, testing, validation, and operations—making agents regular collaborative partners rather than occasional aids. This intensive AI practice not only dramatically improves delivery efficiency, but also cultivates a cohort of technical talent familiar with Uber’s business systems and skilled in AI deployment, opening a critical talent pipeline for spreading AI to non‑technical functions.
This is no longer about “what to do with AI”—it is about “what the organisation itself should become.” Uber has given us a fairly clear slice of the answer—and that, perhaps, is the part most worth chewing over in this entire share.