Forward-deployed AI consulting
Forward-deployed AI consulting is for organisations that have an AI pilot which has not reached production, or a workflow where an agent could change how work is done but nobody has yet decided how to build it safely. I work with the people who own that workflow and with the engineers who will run it afterwards.
I am Mayur Patil, based in Nashik, India. I co-founded Aurelia Innovatives Pvt. Ltd., the firm that contracts this work, and I travel for engagements. The work is delivered by me, with your team alongside. It is not handed to a rotating group of junior staff.
What a forward-deployed consultant does
A forward-deployed engineer works inside the client's environment, close to the problem, rather than from a distance. The role is described in more detail on the forward-deployed engineering page, and the terms are defined in the glossary. In practice, this means four things.
First, the work starts from the real workflow. I map the steps, the people, the systems and the records, and I sample real cases before I propose anything. Second, the architecture is decided with your team and recorded, including the options rejected and why. Third, the first working version runs on your data, scored against an evaluation set that the business owner agrees. Fourth, the system is handed over with a runbook and a named owner.
A traditional advisory engagement often stops at the recommendation. That is a useful product, and my first engagement type is exactly that. Forward-deployed delivery goes further, and the difference matters when a pilot has already produced a demonstration but no production system.
Three ways to engage
AI Delivery Readiness Review. Two weeks on one workflow or pilot. I review what exists, speak to up to five people who own or do the work, and produce a written readout covering the problem and the outcome that matters, the workflow and who owns each part, whether data, access and evaluation are ready, the options with their trade-offs, and a recommendation to proceed, reframe or pause. The recommendation may be to stop. See the AI Delivery Readiness Review for the decision it produces.
Architecture Sprint. Two to four weeks on one agreed use case. It produces a solution architecture with data and integration boundaries, the decisions on models, retrieval and agents with their reasoning recorded, an evaluation and acceptance plan, and a prioritised delivery backlog. Your team can build from it without me.
Forward-deployed AI delivery. One bounded use case, built inside your systems. Scope, responsibilities and acceptance criteria are written down before the build starts. I lead the architecture and the critical technical decisions, your engineers work alongside me, and the engagement ends with the agreed implementation, evaluation results against the agreed tests, and a runbook handed to a named owner. It is scoped per engagement and paid by milestone.
Each of these is quoted on its scope. The engagements page describes what each one includes in more detail.
What you receive
The outputs are things you keep, not workshop notes. A readiness readout is a document your board or your risk team can read. An architecture sprint leaves a set of recorded decisions and a backlog. A delivery engagement leaves working software, the evaluation results and a handover pack, which is described in the handover pack term.
The most important output is often the list of things we decided not to build. A written decision to pause a workflow, with the reasons recorded, saves more money than a rushed build that cannot be evaluated.
Who this is for
The usual buyer is the person who owns a workflow and has been asked to show results: a head of operations, a head of data, a CIO's delegate, or a leader of a services firm that is building AI for its own clients. The engagement works best when that person can name the workflow, the outcome that matters and the people who will use the result.
I work across sectors. The clients I can name are listed where they have agreed to be named, and I do not publish details of work where the client has not agreed. Where a regulation applies to the workflow, the country page for that market summarises the rules and links to their sources, so the consulting conversation starts from the rules and not from a summary of them.
Where I work
Each market has its own page, which covers the rules that apply to an agent and what they mean for the build:
- AI agents in the UAE
- AI agents in the United States
- AI agents in Singapore
- AI agents in Europe
- AI agents in India
For organisations that run several delivery centres, the global capability centres page covers the operating-model questions that come up when the engineering function sits inside a centre.
What changed in 2026
The market for forward-deployed work in India changed this year, and the change matters for how a buyer should choose a partner. The Nasscom-Zinnov India GCC Landscape report released in July 2026 counts 2,117 GCCs in India, reported as employing about 2.36 million people and generating just under $100 billion in FY26 revenue. The same coverage reports that more than 1,200 GCCs in India have embedded AI and machine learning capabilities, supported by more than 250 dedicated centres of excellence. The figures come from news reports of the report, and the Nasscom-Zinnov report is the reference.
A second theme is maturity. A 2026 Dell and Zinnov study of more than 50 senior GCC leaders reports that about 27 per cent of new GCCs reach a portfolio-hub level within five years, compared with nearly a decade historically, and that about 70 per cent have a defined AI roadmap. Buyers in this market therefore ask less often whether a centre can build, and more often whether it can own what it builds.
For buyers in Singapore and the Gulf, the same pattern holds with a different regulator. The Singapore pillar describes the 2026 IMDA framework and the MAS guidelines, and the UAE pillar describes the federal data law and DIFC Regulation 10.
Where the work is
I work across five markets, and each has a place page for consulting. The link names the country pillar that holds the rules for that market.
- Singapore. Banks and enterprises moving agents through the IMDA testing steps. See the Singapore consulting page and the Singapore pillar.
- Dubai. Enterprises that must answer to the DIFC question before the build. See the Dubai consulting page and the UAE pillar.
- Bengaluru. Capability centres moving AI work from pilots into production. See the Bengaluru consulting page and the India pillar.
- Hyderabad. A fast-growing centre hub with a state AI mission. See the Hyderabad consulting page.
- Abu Dhabi. Government entities and enterprises building under the emirate's AI-native plan. See the Abu Dhabi consulting page.
- Mumbai. Banks, insurers and centres where the BFSI units are concentrated. See the Mumbai consulting page.
- Pune. Manufacturing, automotive and IT services teams. See the Pune consulting page.
- Europe. Teams building under the EU AI Act, with the approval and record duties designed in. See the Europe consulting page.
- India. The country view for enterprises and centres, with the DPDP timeline. See the India consulting page.
- The Bay Area. Teams building agents for US customers, with the state laws in view. See the Bay Area consulting page and the United States pillar.
What a first engagement looks like
Most engagements begin with the two-week AI Delivery Readiness Review on one workflow. The review has four parts. First, the outcome that matters and the person who owns it. Second, the data the workflow needs, and whether the data owner has agreed to its use. Third, the evaluation: what a correct result looks like, written in a form the owner can check. Fourth, the controls: which actions need a person to approve them, and who answers if the agent is wrong.
The review ends with a written recommendation to proceed, reframe or pause. A pause is a valid result, and it is often the cheapest one. If the recommendation is to proceed, the next step is an architecture sprint, which decides the design, or a forward-deployed delivery engagement, which builds the first system with your engineers beside me.
Who decides
A buyer is rarely one person. The business owner decides what the agent is for. The data owner decides what it may read. The risk or legal team decides which controls are required. The engineering lead decides how the system is run after handover. An engagement that names all four at the start moves faster, because each decision is made once, in the room, and recorded.
How I work with buyers
I work with the people who own the workflow, and with the engineers who will run it afterwards. I am based in Nashik, India, and I am in Singapore, Dubai, Bengaluru, Hyderabad and Pune often for engagements. Discovery and handover can be on site, and the build can run from India with a fixed overlap for decisions. Outside those cities, the work is arranged per engagement.
What the buyer's team commits to
An engagement works when the buyer's side is ready. Three commitments are usually enough. The business owner gives one afternoon a week to decide what the agent should and should not do. The data owner confirms, in writing, which data the workflow may use and for what purpose. The engineering lead names one person who will own the system after handover, and that person joins the build from the first week. Without these, the build waits, and the agent is never handed over.
Risks we plan for
Most risks in an AI build are known before the build starts, and the readiness review names them. The commonest are data that is harder to reach than the buyer expected, an evaluation set that nobody agreed, an agent that can change a record without an approver, and a model whose behaviour shifts after a vendor update. Each has a control written down before the first run: an access review, a signed evaluation set, an approval step, and a re-run of the evaluation after each change.
Questions I ask in the first meeting
The first meeting is short, and it is always the same. What is the workflow, and where does it stall today? Who decides when it is finished? Which systems does it touch, and who owns each? What has already been tried, and what did it show? The answers decide whether a readiness review is the right first step, or whether the workflow needs more preparation first.
Why the first step is small
A first engagement is deliberately small. One workflow, one owner and one set of data keeps the decision clear, and it shows within a few weeks whether the wider programme is worth funding. Buyers who start small tend to expand the work once the first system runs, because the evidence is in front of them and the owner has been part of it from the start.
How to start
Send an enquiry with the use case, where progress is blocked and who is involved. I reply with a suggested starting point, which is usually a readiness review, and a proposal once the scope is clear. If the work is about learning the method yourself, rather than buying delivery, see the FDE training page.
Common questions
What does a forward-deployed AI consultant do that a traditional consultant does not?
A traditional consultant may end with a report. A forward-deployed consultant works inside the client's systems, decides the architecture with the team, builds the first working version, and hands it to a named owner. The engagement ends when the system runs, not when the document is delivered.
Do I have to buy a second engagement after the readiness review?
No. The readiness review ends with a written recommendation to proceed, reframe or pause. The recommendation may be to stop, and you can act on it with your own team.
How are engagements priced?
I do not publish prices. Every engagement is quoted on its scope. Send an enquiry with the use case, where progress is blocked and who is involved, and I reply with a proposal.
Do you work outside India?
Yes. I have worked with clients in the United States, the United Kingdom, the UAE, Singapore, Malaysia, India, Italy, Switzerland, South Africa and Mauritius. I am based in Nashik, India, and travel for engagements.
Who owns the system after the engagement?
A named owner inside your organisation. Each delivery ends with a runbook, the evaluation results and the recorded decisions, handed over to that owner.
Can you help with a system that is already in production?
Yes, if the problem is clear. The readiness review can start from a live system, and the first output is the same written recommendation.