Key takeaway: 95% of enterprise generative-AI pilots fail to show measurable ROI. Uber closed that gap with “Agentic Pods” – engineer-and-domain-expert pairs on a 10-day sprint – running 16 pods across 16 business functions in two months, with results like a 15-hour finance workflow cut to 30 minutes. This playbook is for CTOs, ops leaders, and finance/HR/support heads who want AI to survive contact with real workflows, not just a pilot deck.
Most enterprises are buying copilot seats and hoping for magic. The companies pulling ahead are doing something harder and far more valuable: rebuilding their actual workflows around AI agents. Here is a practical playbook, plus a detailed look at how Uber put it into practice.
Why Do Most Enterprise AI Pilots Fail?
Most companies approach corporate AI the same way. They buy thousands of generic copilot seats, roll them out across the org, and wait for the productivity curve to bend. A few months later the picture is familiar: a large monthly software bill, marginal gains, and employees who mostly use AI to rewrite their emails.
The data backs up the disappointment. MIT’s research on enterprise AI found that roughly 95% of corporate generative-AI pilots produced no measurable business impact. The models are not the weak link. Instead, the problem is that off-the-shelf copilots are built for isolated task completion, while real corporate work is messy, manual, spread across a dozen legacy systems, and almost never documented the way it actually happens. A copilot can help you write a paragraph. It cannot run the seven-system, approval-heavy process your finance team grinds through every Monday.
Piping every task through an external model API and calling it a strategy has a nickname among engineers: “tokenmaxxing.” It looks like progress on a dashboard. but it rarely shows up in the P&L.
The Real Bottleneck Is Deployment, Not the Model
The AI industry has reached the same conclusion, and it is spending billions to fix it. Between May and July 2026, four of the biggest names in AI (Anthropic, OpenAI, AWS, and Microsoft) committed roughly 9 billion dollars combined to a single idea: embedding their own engineers directly inside customer organizations to make AI work in production. For example, AWS alone put 1 billion dollars into a Forward Deployed Engineering unit that drops pods of five or six engineers into a customer to build systems in their own environment. Microsoft announced a 2.5 billion dollar division for the same purpose. Job postings for these “forward deployed engineers” have climbed roughly 800% in a year.
The common thread is simple: a great model is not a great outcome. Someone has to sit inside the building, learn how the work really gets done, and build the thing that turns a raw capability into a result. You do not have to hire an outside vendor to do this. The most effective version of the model is to build it in-house.
The Playbook: Agentic Pods
The core structure is a lean, cross-functional squad, call it an Agentic Pod. Each pod pairs one AI-proficient engineer, someone who already understands your internal systems and data, one-to-one with a domain expert from an operational function like finance, HR, or support. No consultants drawing high-level roadmaps. No off-the-shelf tool the business team is left to adopt on its own. Just a builder and a doer, side by side, redesigning one workflow at a time.
Two rules make it work. First, use internal engineers, because they already know your APIs, microservices, and data structures, which lets them integrate an agent natively instead of bolting one on. Second, put them next to the people doing the manual labour. That’s because real shortcuts, compliance nuances, and software friction only become visible from the inside.
How Does the 10-Day Sprint Framework Work?
Give every pod a hard two-week deadline and a repeatable cycle. The deadline is not incidental. It forces the team to ship something real instead of polishing something perfect.
Days 1-2, Shadow. The engineer sits beside the domain expert, watches every click, tracks the handoffs between systems, and documents the unwritten habits that never make it into a manual.
Day 3, Prioritize. The pair ranks opportunities by scale, repetition, business impact, and whether the underlying data is actually available.
Days 4-5, Build. Engineer and expert build a working agent together, so it fits the real tools and steps rather than an idealized version of them.
Days 6-9, Validate. The agent is tested against several other people doing the same job, to confirm it generalizes across the team and genuinely improves the work.
Day 10, Ship. The agent goes straight into the production workflow.
Three Principles for Enterprise AI That Works
- The workflow is the unit of automation. The biggest gains rarely come from automating a single task, like drafting an email. They come from redesigning an entire multi-step workflow around an agent. When an agent owns a process end to end, it naturally removes unnecessary approvals, unifies scattered vendor tools, and cuts legacy friction that no one previously had the authority to fix.
- Solve the agent identity problem early. More autonomy means more scrutiny of what agents are allowed to do. Before an agent acts on behalf of an employee, your identity and access stack has to be ready for it. Role-based access control, query validation, and clear data attribution are what keep auditing, compliance, and security intact once the agent is the one taking the action.
- Build with your workers, not for them. You cannot design an elite agentic system from the outside looking in. The real friction points only surface when a builder sits next to the person doing the job every day. That is exactly why the sprint starts with two full days of shadowing before anyone writes a line of code.
A Detailed Example: How Uber Put This Into Practice
The clearest real-world proof of this model comes from Uber.
From Engineering to Every Business Function
Uber first saturated AI inside its own engineering org. By CTO Praveen Neppalli Naga’s account, 99% of Uber engineers now use AI tools, more than 70% of pull requests are attributed to local or cloud agents, and engineers have built over 2,500 agent skills across the software development lifecycle. That success raised a sharper question: if AI had already transformed how Uber builds software, what would it take to transform finance, legal, marketing, support, HR, and procurement?
In response, Uber’s answer was Agentic Pods. It handpicked around 30 of its most AI-proficient engineers and paired each with a domain expert from a business function, giving every pod exactly two weeks and the ten-day sprint described above. As Naga put it, you have to understand how the work actually gets done, because process diagrams never capture the copy-paste steps and informal approvals that make up the real thing.
The Results: 16 Pods and Uber’s Finch Finance Agent
In two months, Uber ran 16 Agentic Pods across 16 different business functions. The reported time savings:
| Business function | Operational task | Before | After |
|---|---|---|---|
| Finance and Treasury | Capital allocation modeling across 150 global cities | 15 hours | 30 minutes |
| Corporate Finance | Financial pacing and budget runway reports | 2 days | 10 minutes |
| Marketing Operations | Localized web quality assurance | 2 weeks | 50 minutes |
| Customer Support | Building complex routing and support logic | 9,000 manual workflows | Self-service automation |
Take one agent in detail. “Finch” now lives inside Slack for Uber’s finance teams. Instead of writing SQL across multiple platforms, an analyst asks a plain-English question like “What was gross bookings in the US and Canada last quarter?” and gets a governed, permission-checked answer in seconds. Under the hood, Finch uses a supervisor agent that routes each question to specialist sub-agents, orchestration built on LangGraph, and role-based access control that enforces who can see what. A simplified version of that routing logic looks like this:
from langgraph.graph import StateGraph, END
from typing import TypedDict
class FinchState(TypedDict):
question: str
user_role: str
route: str
answer: str
# Role-based access control runs before any data is touched
def check_access(state: FinchState) -> FinchState:
allowed = {
"analyst": ["bookings", "pacing"],
"admin": ["bookings", "pacing", "payroll"],
}
topic = classify_topic(state["question"])
if topic not in allowed.get(state["user_role"], []):
state["answer"] = "Access denied for this data domain."
state["route"] = "end"
else:
state["route"] = topic
return state
# Supervisor routes each question to the right specialist sub-agent
def supervisor(state: FinchState) -> str:
return state["route"]
def bookings_agent(state: FinchState) -> FinchState:
state["answer"] = run_governed_query("gross_bookings", state["question"])
return state
def pacing_agent(state: FinchState) -> FinchState:
state["answer"] = run_governed_query("budget_pacing", state["question"])
return state
graph = StateGraph(FinchState)
graph.add_node("access", check_access)
graph.add_node("bookings", bookings_agent)
graph.add_node("pacing", pacing_agent)
graph.set_entry_point("access")
graph.add_conditional_edges(
"access",
supervisor,
{"bookings": "bookings", "pacing": "pacing", "end": END},
)
graph.add_edge("bookings", END)
graph.add_edge("pacing", END)
finch = graph.compile()
result = finch.invoke({
"question": "What was gross bookings in the US and Canada last quarter?",
"user_role": "analyst",
})
print(result["answer"])
Large result sets export automatically to a linked spreadsheet. Speed never comes at the cost of security or auditability.
What surprised Uber most was not the speed. It was how quickly engineers dropped into unfamiliar departments started spotting problems that insiders had stopped noticing, opportunities that were, in Naga’s words, hiding in plain sight. Uber is now forming a dedicated team to scale the approach and go deeper, treating workflow redesign as a permanent discipline rather than a one-time experiment.
A Word on ROI
However, none of this justifies itself automatically. Uber’s own leadership has been candid that heavy AI investment has not yet produced a proportional wave of new consumer features, and that the cost deserves close scrutiny. Set against MIT’s 95% pilot-failure figure, the lesson is clear. The workflow-first model earns its keep precisely because it ties AI spend to specific, measurable tasks: hours saved on a named report, weeks compressed on a real QA cycle, rather than to a seat count and a hope. If you cannot point to the workflow and the hours it gave back, you are probably still tokenmaxxing.
Frequently Asked Questions
What is an Agentic Pod?
An Agentic Pod pairs one AI-proficient engineer with one domain expert from a business function like finance or HR, on a fixed 10-day sprint to build and ship a working AI agent for a real workflow.
Why do most enterprise AI pilots fail?
MIT’s research found 95% of corporate generative-AI pilots show no measurable business impact, mainly because generic copilots aren’t built for the messy, multi-system workflows that make up real corporate work.
How is an Agentic Pod different from a typical AI pilot or consultant engagement?
A typical pilot hands the business a generic tool and hopes it fits. An Agentic Pod embeds an internal engineer directly with the person doing the job for two days of shadowing before any code is written, so the agent is built around the real, undocumented workflow rather than an idealized version of it.
How do I start an Agentic Pod without Uber’s resources?
You don’t need 30 engineers or a dedicated team. One AI-fluent engineer, one willing domain expert, a hard two-week deadline, and a single high-friction workflow with existing data is enough to run a first pod and measure the hours it returns.
Getting Started
You do not need Uber’s scale to copy this. The ingredients are modest: a few AI-fluent engineers, willing domain experts, a hard deadline, and a rule that you observe the work before you automate it. Start with one or two high-friction workflows where the data already exists, run a single two-week pod, and measure the hours it returns.
The most profitable AI opportunities in your company are probably not sitting in a vendor’s product roadmap. They are hiding in your messiest, most manual, everyday operations. You just have to send your best builders onto the floor to find them.