Forward deployed consulting essentials for business

We recently submitted a proposal where the planning sprint had to be bespoke. The client's business was live. Its data and processes were live. Whatever we built would have to work inside that business, with the consequences of getting it wrong borne by an organization who still had customers to serve.

Unlike my past experience in an agency where no amount of ideation or strategy is paid, I see that in technical implementation this is paramount. It is the business. The engineering is important but if the plan is wrong or details about data, systems and business functions are missed or wrongly understood, the resulting implementation could put the client business in serious danger. An engineer needs to understand what a process actually does before inducing AI processes into it.

The AI companies are paying to understand the client's business

That is also where the market is moving. On October 2, Anthropic committed $100 million to an academy intended to train 10,000 Frontier Deployed Engineers by the end of 2027. Participants work through a simulated enterprise deployment, then take a real project back into their own organization for a 12-week residency. The company selling Claude is investing in people who can get it working inside a customer's operation. Access to the model has not removed that job. Anthropic's announcement

OpenAI is building a delivery business of its own. Its May announcement describes engineers working with leaders and frontline teams, starting with a diagnostic and choosing priority workflows before building systems connected to the customer's data and controls. It also announced an agreement to acquire Tomoro for its deployment experience. There is a reason to buy an existing team: knowing how to make a model answer is a smaller job than knowing how to change the work a company does every day. OpenAI Deployment Company

The commercial implication is quite straightforward. The model suppliers need customers to use more of their technology, but the customer needs a business result it can live with. An implementation team has to reconcile those interests. Sometimes the most useful finding will be that the proposed automation should stop at a recommendation, because letting it execute the decision creates more exposure than the saving justifies.

Microsoft's Frontier Company makes this particularly clear. It combines engineering with industry knowledge, change management and continuing improvement. Microsoft announced $2.5 billion of investment and 6,000 industry and engineering experts for the business. It is selling the work required to change an organization, including what happens after the first deployment. That is a much larger commitment than handing a client a working demo. Microsoft's announcement

Google Cloud is putting its engineers alongside consulting partners too. Its April announcement describes forward deployed engineers working with major systems integrators, including a joint program with Accenture, to deploy AI in customer businesses. For a buyer, this means even the company supplying Gemini expects implementation to need people close to the customer. The model vendor brings product knowledge. The consulting team and the client still have to establish how it fits the work, who can authorize its actions and how the business will accept the result. Google Cloud’s announcement

Palantir has organized around customer problems for much longer. Its careers explanation distinguishes a product engineer developing a capability for many customers from a forward deployed engineer applying several capabilities to one customer's needs. The customer context is the organizing principle. xAI also offers forward deployed implementation, though its public government offer specifically involves cleared engineers. The offers differ, but each puts people close to the work the technology is supposed to change. Palantir, xAI

A discovery sprint has to expose what a demo leaves out

Consider an AI system proposed for handling customer refunds. Reading a message and drafting a response is the easy demonstration. The actual business has settled payments, disputed deliveries, fraud checks, exceptions for important accounts and someone who has to close the books. A model that understands the customer's complaint can still recommend a refund the company cannot reconcile.

Before engineering starts, the team needs to follow an actual case through that process with the people running it. Which record is authoritative? Who can authorize an exception? What happens if the payment system reports success but the order system does not update? These answers change the design. They determine what the model may read, what it may propose and which action still needs a person.

That is why I support paying for discovery. The work creates decisions the implementation depends on. A client should be able to take the resulting scope and understand the operating change being proposed, its risks and the evidence needed to accept it. If the sprint concludes that the data is unreliable or that a cheaper process change solves the problem, the client has bought an answer before paying for the wrong build.

There is a supplier obligation here too. Discovery cannot be an open-ended exercise that keeps finding reasons to sell more discovery. It should finish with a bounded implementation decision and the unresolved assumptions stated plainly. The client needs to know what the next phase will deliver and what would cause it to stop.

Businesses and brands need to manage the change

Hiring an external team does not give it the knowledge held by the people who run the process. They need to explain the approvals, exceptions and records that matter. An engineer cannot infer those rules from a spreadsheet and be expected to make safe changes to a live business.

The client also needs to help define acceptance. A fluent answer in a demonstration does not show whether the system handles a disputed payment, refuses an action it should not take, or leaves a person able to resolve an exception. The people responsible for the work should agree on those cases before the system goes into production.

Outside consulting is not necessary for every workflow. Anthropic's academy is designed to help engineers lead a real use case in their own organization with support from Anthropic engineers. A business with the right people and a well-understood process may be able to build that capability internally. An external team earns its fee when it fills a real gap in understanding or delivery, and carries what it learns into the implementation.

That is the standard I would use when buying forward deployed consulting. Pay for discovery when it establishes what the business needs, what can safely change and how the result will be accepted. Then make sure the people who own the process stay involved. The engineer can build the system, but the business has to live with its decisions on Monday morning.