Source: raw/How_to_Help_People_Thrive_with_AI.md — The AI Daily Brief (NLW) episode reading and commenting on a public tweet by Uber CTO Praveen Napali (yt-podcast transcript). The numbers below are Napali’s first-party claims relayed via the podcast; they are not independently verified here.
Uber’s “agentic pods” are a concrete, repeatable org-design pattern for pushing agentic AI out of engineering and into finance, legal, ops, marketing, support, HR, and procurement — the functions that run on manual, nuanced workflows spread across dozens of systems. The core move: pair an AI-proficient engineer with a domain expert, embed for a fixed 10-day sprint, and ship one working agent per pod. It’s a practical answer to the recurring adoption problem the wiki tracks — that the highest-value automations aren’t visible from process diagrams; you have to sit next to the person doing the work.
Key Takeaways
- The starting condition (engineering). Napali’s stated Uber baseline: 99% of engineers use AI tools, >70% of pull requests are attributed to local or cloud agents, and engineers have built 2,500+ agent skills across the software-development lifecycle. The pods are the attempt to reproduce that outside engineering.
- The pod = builder + domain expert. ~30 of Uber’s most AI-proficient engineers (people with deep knowledge of Uber’s systems), each paired with one domain expert from a business function.
- Fixed 10-day cadence (see below) — shadow → prioritize → build → validate → ship. The time-box is the discipline.
- Scale so far: 16 pods across 16 business functions in ~2 months.
- The reframe: “the workflow becomes the unit of automation, not the individual task.” The biggest wins came from redesigning an entire workflow around AI — eliminating handoffs, removing unnecessary approvals, replacing legacy tooling, cutting vendor spend — not from automating one step. The most impactful skills cut across teams, orgs, functions, tools, and systems.
- The lesson: opportunities are invisible from the outside. You find them “by sitting next to the people doing the work, understanding every friction point, and building with them, not for them.” Embedding engineers in unfamiliar domains surfaced wins hiding in plain sight — that discovery, not raw speed, was the surprise.
The 10-Day Pod Cadence
| Days | Phase | What happens |
|---|---|---|
| 1–2 | Shadow | Observe the expert’s every step, document workflows, ask questions, build intuition |
| 3 | Prioritize | Rank opportunities by scale, repetition, business impact, and data availability |
| 4–5 | Build | Build a working agent alongside the person doing the job |
| 6–9 | Validate | Test with several others doing the same work — does it generalize? does it actually make the job better? |
| 10 | Ship | Deliver the working agent |
Reported Results (first-party, per Napali)
- Capital allocation across 150 cities: 15 hours → 30 minutes
- Financial pacing reports: 2 days → 10 minutes
- Marketing web QA: 2 weeks → 50 minutes
- Support workflow creation: 9,000 manual workflows → self-service automation
Uber is “now forming a dedicated team to scale this further.”
Why It Matters
This is a transferable adoption blueprint, not just a case study. It operationalizes two theses the wiki already carries: that AI has moved the bottleneck from doing the work to understanding and verifying it (the verification frontier), and that 2026-era value comes from restructuring work rather than speeding up tasks (2026 AI-Work Restructuring). The pod model is a cheap, time-boxed way to find the cross-functional workflows worth rebuilding — the same “sit with the operator, encode their judgment” pattern Anthropic used internally for self-service data analytics (skills co-located with the people who own the data).
Try It
- Run one pilot pod. Pick your most painful cross-system business workflow (finance close, marketing QA, support triage). Pair one AI-fluent builder with the person who actually does that job. Time-box to ~2 weeks with the shadow → prioritize → build → validate → ship phases.
- Prioritize on the four axes — scale, repetition, business impact, data availability — before building. Skip anything low on data availability; the agent needs a legible signal to work from.
- Design for the workflow, not the task. Before automating a step, ask what handoffs, approvals, or legacy tools the redesign could remove entirely. That’s where the compounding wins are.
- Build with the operator, validate with peers. The person doing the job co-builds (days 4–5); several others doing the same job pressure-test generalization (days 6–9). This is the guardrail against a demo that only works for one person.
Related
- 2026 AI-Work Restructuring — the macro thesis (roles merging, workflow-as-unit) this is a concrete field instance of.
- Self-Service Data Analytics (Anthropic’s Internal Playbook) — the same “encode the operator’s judgment, co-locate with the work” pattern inside Anthropic.
- High-Trust Paperwork Agent Skeleton — how to build the individual business-function agent a pod ships.
- Running an AI-Native Engineering Org (Fiona Fung) — Anthropic’s own team-norm rewrites for the same shift, on the engineering side.
- Asana AI Teammates — the productized version of per-function agents across a business.
Open Questions
- The metrics are a single first-party tweet relayed via a podcast — no independent verification, no baseline methodology, and “attributed to agents” for >70% of PRs is undefined (authored vs. touched vs. suggested).^[ambiguous]
- Durability/quality of the shipped agents past the 10-day sprint (maintenance, drift, who owns them) is not addressed.
- What tooling the pods build on (internal platform vs. off-the-shelf) is not stated in the source.