Forward-deployed now means learning together

Working together

Wipro's plan for 1,500 embedded AI engineers joins a wider movement toward teams that build with clients and leave them able to continue alone.

The client team moves from explaining the work to reviewing, improving and owning the system. Common Intelligence

Published: 27 August 2026
Written by: Common Intelligence
Section: Working together

Wipro and Google Cloud announced on 27 August that they are preparing more than 1,500 forward-deployed engineers. OpenAI and AWS have launched comparable organisations this year. The common idea is simple: important AI systems are built with customers, not delivered to them.

An embedded engineer can see the difference between the documented process and the one people actually use. That matters because the exceptions, controls and responsibilities that keep an operation safe are often held by the team rather than by the software.

Build with the people doing the work

The strongest version of the model treats those employees as partners in the build. They select the real cases, explain why an apparently unusual decision was correct, test the first releases and help define when the system must stop and ask for review.

AWS makes the goal explicit: customer engineers should move from observers to co-builders to autonomous operators. The engagement is not successful if capability remains with the supplier or if the team must request every future change from outside.

Capability that stays

This approach also makes adoption less abstract. People learn the system while solving their own work, not in a separate training programme. They can see which parts remove repetition and which decisions still need their judgment.

The growth of forward deployment is therefore more than a services trend. It is a recognition that technical capability and organisational capability must be built together if AI is going to remain useful after the first launch.

Sources

Talk it through

Leo LargilletChief executive

Available this week

Bring a process your team knows should work better. In forty-five minutes, we will listen to how it really runs, identify where AI could help, and be clear about what we would leave with people.

Frequently asked

Our work starts from the people already responsible for the operation. The aim is to remove repetitive search, comparison and drafting, while making their judgment easier to apply and keeping accountable decisions with named human owners.
They help map the real process, choose the difficult cases, test early versions and define where review or refusal is required. An internal group learns to operate and improve the system before handover.
One senior sponsor, access to the people and systems involved, and agreement on the business measure before building begins. Leadership also protects time for operators to participate, because their knowledge is part of the system.
It should be frequent, expensive, evidence-heavy and close to a measure the company already trusts. The two-week diagnostic compares candidate workflows and tests the strongest one on real company data.
That is why it is tested on real exceptions before production. Corrections become part of the evaluation set, and the system is designed to ask for review when evidence is weak rather than appearing certain.
We build in the client environment wherever possible, use the minimum permissions each action needs, and make activity auditable. Data boundaries, retention, human review and prohibited actions are agreed before a production release.
The engagement is designed to reduce that dependency. The client receives the source, prompts, evaluation cases, runbooks and controls, and proves the handover by running the next cycle with its own team.
We establish the current cost and operating baseline together, then review the same measure after each release. If the workflow does not produce a credible financial or operating improvement, we do not expand it.