Enterprise AI has a quick-win problem.
Organizations are being encouraged to collect AI use cases, place them into a prioritization matrix, and start with the opportunities that appear easiest to implement. The result is usually a backlog filled with assistants, document summaries, isolated automations, and small productivity features.
Some of these applications are useful. But they rarely change how the organization operates.
Uber’s recent introduction of Agentic Pods illustrates a different approach. Instead of asking business departments to submit AI ideas, Uber placed Forward Deployed Engineers (FDEs) directly alongside employees in finance, legal, HR, marketing, operations, procurement, and customer support. A Forward Deployed Engineer is an AI Expert who works inside the business function rather than in a central platform team: close enough to the process to see it, senior enough to build against it.
The FDEs observed how people actually worked, built agents with them, tested the results with additional users, and shipped working solutions within two weeks.
The important lesson is not simply that Uber is using AI agents. The lesson is that the most valuable AI opportunities cannot always be identified from outside the process.
They have to be discovered inside the work.
Uber CTO Praveen Neppalli Naga described the approach in an original post on X. Uber reportedly deployed 16 Agentic Pods across different business functions. Among the results were a reduction in capital-allocation work from 15 hours to 30 minutes, financial pacing reports falling from two days to 10 minutes, and marketing quality assurance dropping from two weeks to 50 minutes.
Executive Summary: What Agentic Pods Change About Enterprise AI
Uber replaced the familiar use-case workshop with an embedded delivery team: a Forward Deployed Engineer sits next to the person who owns a process, observes how the work is really done, and ships a working agent within two weeks. The reported numbers are striking, but the mechanism behind them matters more. High-value AI opportunities are usually invisible from outside a process, because the people asked to nominate them cannot fully describe the exceptions, workarounds, and cross-system handovers that make their work expensive. For any organization assembling an AI portfolio, this moves the central question away from which use case is easiest to start with, and toward which workflow would look fundamentally different if it were designed around what AI can do today.
Key Takeaways:
- Discovery belongs inside the work: The most valuable workflows are the hardest to articulate in a workshop, so they lose to simpler, more visible ideas in a prioritization matrix.
- The workflow is the unit of automation: Automating a single task inside an unchanged process produces local speed without removing the organizational friction around it.
- Prioritization needs AI-specific criteria: Frequency, data availability, reuse potential, the cost of being wrong, and post-launch ownership predict value far better than urgency and importance.
- Building is a form of discovery: A working prototype surfaces missing data, hidden process rules, and integration constraints that no current-state analysis anticipates.
- A pod is a delivery mechanism, not an operating model: Without decision rights, access rules, ownership, and monitoring, an organization accumulates isolated agents the way it once accumulated isolated proofs of concept.
What Is an Agentic Pod?
An Agentic Pod is a small, temporary, cross-functional delivery team that brings together:
- a person who understands the business process in detail;
- a Forward Deployed Engineer — the AI Expert on the pod, who understands AI agents, data, software, and the company’s systems;
- a clearly bounded workflow that can be observed, redesigned, built, and validated.
At Uber, the pod followed a compressed ten-day process:
- Shadow the domain expert and observe the real work.
- Document the workflow, including exceptions and workarounds.
- Prioritize opportunities based on repetition, scale, business impact, and available data.
- Build a working agent alongside the person performing the process.
- Validate whether it works for other employees.
- Ship the solution.
This is not a traditional automation workshop. It is closer to an embedded product and engineering intervention.
The domain expert does not hand over a process description and wait for a solution. The FDE does not disappear for three months to build against a requirements document. Both work on the process together.
Why Quick-Win Prioritization Misses the Real Opportunities
The usual AI opportunity process begins with interviews or workshops.
Stakeholders are asked where they lose time. The ideas are collected in a spreadsheet and evaluated according to criteria such as effort, impact, urgency, feasibility, and strategic relevance.
This produces a visually convincing portfolio. But it has a structural weakness: it prioritizes what participants can already articulate.
Many high-value workflows are difficult to describe because they include:
- information spread across several systems;
- undocumented judgment calls;
- manual transfers between departments;
- spreadsheets maintained outside formal processes;
- exceptions known only to experienced employees;
- approvals that exist because of historical constraints;
- workarounds that have become part of daily operations.
A process diagram normally shows how work is supposed to happen. An embedded FDE sees how it actually happens.
That distinction matters because AI agents are especially valuable when a workflow crosses systems, interprets information, makes bounded decisions, and coordinates multiple steps. These opportunities often look too complicated in a workshop and therefore lose against a simpler chatbot or summarization tool.
The quick win wins the matrix.
The valuable workflow remains untouched.
Stop Using the Eisenhower Matrix for AI
The Eisenhower Matrix distinguishes between urgent, important, non-urgent, and less important tasks. It is useful for personal task management.
It is not an adequate framework for enterprise AI investment.
AI initiatives must be evaluated against a different set of questions:
- How frequently is the workflow executed?
- How much organizational capacity does it consume?
- How many systems and handovers are involved?
- Which decisions require human judgment?
- Is sufficient data accessible?
- Can the resulting capability be reused elsewhere?
- What happens when the agent is wrong?
- Who will own the system after deployment?
- Can the workflow itself be redesigned rather than merely accelerated?
A process can be neither visibly urgent nor strategically prominent and still consume thousands of hours across an organization.
Conversely, an urgent task might be a poor candidate for AI because it occurs infrequently, lacks reliable data, or carries unacceptable operational risk.
An effective AI strategy therefore cannot be reduced to selecting the easiest items from a use-case backlog. It must connect business value, technical feasibility, organizational dependencies, architecture, sourcing, ownership, and measurable success criteria.
The Workflow Must Become the Unit of Transformation
Many AI projects attempt to automate one task within an unchanged process.
An agent drafts the email, but the employee still collects the information manually.
A model extracts the document data, but somebody still transfers the results into another system.
A copilot generates the report, but the approval chain and underlying data preparation remain untouched.
This creates local productivity gains without removing the broader organizational friction.
Uber’s approach instead treats the workflow as the unit of automation. The objective is not simply to make one employee faster. It is to examine the full chain of work and ask:
- Which steps can disappear?
- Which handovers are no longer necessary?
- Which information can be retrieved automatically?
- Which decisions can be prepared or executed by an agent?
- Where must a person remain in control?
- Which legacy tools or external services become unnecessary?
- How should the redesigned process be monitored?
This is where agentic systems differ from a conventional chatbot. An agent can interact with tools, retrieve information, execute several steps, maintain state, and escalate decisions according to defined rules.
But the technology only becomes useful when those capabilities are applied to a well-understood operating workflow.
Do not add AI to the workflow. Redesign the workflow around what AI now makes possible.
Building Reveals What Consulting Alone Cannot
Traditional consulting separates discovery from implementation.
Consultants interview stakeholders, analyze the current state, identify opportunities, and develop recommendations. A technical team or external provider is then asked to implement them.
For agentic workflows, this separation can become a disadvantage.
Modern AI systems can be prototyped quickly enough that building itself becomes part of the discovery process. A working agent reveals missing data, hidden process rules, integration constraints, user concerns, and edge cases that no slide deck can fully anticipate.
The sequence changes from:
Understand everything → recommend → hand over → build
to:
Observe → build → learn → adjust → validate
This does not mean strategy, architecture, or governance are no longer necessary. It means they must remain connected to the technical work.
An AI Expert has to operate between management, internal process stakeholders, engineering teams, and external providers. This person must understand the intended business outcome while being capable of challenging technical assumptions and translating discoveries into executable decisions.
That is also the role covered by nAIxt’s AI Project Leadership: connecting management and engineering, establishing requirements and acceptance criteria, steering product and architecture decisions, and ensuring that internal teams and providers deliver against the actual operational objective.
Where the system itself still needs to be defined, AI Product & Systems Architecture turns the discovered workflow into product requirements, system boundaries, data flows, interfaces, human-in-the-loop decisions, and implementation work packages.
Where the technically critical capability must be built and validated, Applied AI Engineering provides the prototypes, models, pipelines, integrations, and production-grade components required to prove that the redesigned workflow performs under real conditions.
Why the Person Setting Up the Agent Matters
Agentic systems are highly versatile, but they are not automatically context-aware.
Their usefulness depends heavily on the person or team defining:
- the objective;
- the available tools and data;
- the workflow sequence;
- the permitted actions;
- the escalation rules;
- the validation criteria;
- the boundaries of human responsibility.
Two companies can use the same model and achieve completely different results.
The differentiator is not only the underlying AI technology. It is the combination of technical capability, process understanding, system access, operational validation, and ownership.
This is why embedding the FDE close to the target process is so effective. Questions are answered immediately. Assumptions can be tested against real examples. Employees can distinguish between an officially documented step and a step that is genuinely necessary.
The process stakeholder contributes operational depth. The AI Expert contributes knowledge of what has become technically possible.
Neither perspective is sufficient alone.
From One Pod to an AI Operating Model
A two-week pod can identify and demonstrate value. Scaling the approach across an organization requires more.
Someone must decide:
- which workflows receive a pod;
- how Forward Deployed Engineers and domain experts are selected;
- which systems agents may access;
- how security and compliance are reviewed;
- how reusable agent capabilities are managed;
- who owns each workflow after launch;
- how performance and failures are monitored;
- how successful prototypes reach stable operation.
Without these structures, the organization accumulates isolated agents in the same way it previously accumulated isolated proofs of concept.
An AI operating model provides the decision rights, portfolio governance, funding processes, provider management, team design, lifecycle ownership, and management reporting needed to turn individual AI initiatives into a sustainable organizational capability.
An Agentic Pod is therefore not the complete AI operating model. It is an effective delivery mechanism within one.
The Strategic Lesson From Uber
Uber’s results should not be interpreted as evidence that every organization needs 30 Forward Deployed Engineers or should copy the same ten-day schedule.
The more transferable lesson is simpler:
Do not expect the best AI opportunities to arrive as completed use-case descriptions.
Place technical capability close to the work. Observe the real process. Build with the people performing it. Validate against operational outcomes. Redesign the full workflow rather than automating the most visible task.
The speed of modern AI development makes this possible. What once required a large software project can increasingly be tested through a focused collaboration between a domain expert and a Forward Deployed Engineer.
That changes the purpose of AI consulting and technical leadership.
The objective is no longer to spend months creating an exhaustive map of possible AI use cases. It is to create a disciplined system for moving between strategy, real-world process discovery, technical validation, and operation.
Stop asking only:
“Where can we find an AI quick win?”
Start asking:
“Which workflow would we design differently if today’s AI capabilities had existed when the process was created?”
That is where the more consequential opportunities begin.