The Incumbent AI Delivery Function Is Hiding in Five Teams

An enterprise buyer asks a practical question after the AI contract is signed: “Who owns the deployment?”

The answer may arrive as five team names.

One group shaped the opportunity. Another provides product guidance. Professional services can be engaged for defined work. Customer success owns adoption conversations. A consulting partner handles implementation. Each scope can be legitimate, yet the buyer still lacks one map of qualification, workflow adaptation, production, adoption, and feedback.

Traditional software vendors can perform forward-deployed work without one FDE organization or title. The incumbent delivery function is often distributed across solution engineering, specialist guidance, professional services, customer success or transformation, and partners. The gap appears when responsibilities and handoffs are mapped across them.

This is a functional model, not a universal org chart. Public pages reveal current program boundaries, not internal reporting lines.

Two current, legible boundaries

Microsoft makes one boundary unusually clear. Its Agent 365 FastTrack documentation, reviewed on August 27, 2026, describes remote guidance for product enablement, identity, controls, lifecycle, monitoring, and operating patterns. It lists project management, hands-on implementation, custom agents, code, APIs, connectors, formal assessments, and ongoing operations outside scope. Microsoft's broader FastTrack page describes engineering guidance and partner options.

That is not evidence of a weak program. It is a useful distinction between guidance and custom implementation. The buyer needs an owner on the other side.

Salesforce exposes another arrangement. Its consulting partner page distinguishes Professional Services and consulting partners and names an FDE Partner Network/category for advanced Agentforce engineering and deployment. Its consulting partners hub describes strategy, integration, governance, context, change, and implementation across an ecosystem.

Those pages establish categories and Salesforce's description of them. A partner label does not prove comparable quality, outcomes, or economics. Nothing in these sources establishes a Scott Felten Consulting affiliation.

The five-team map

The useful unit is responsibility, not title.

The lanes overlap. A provider may allocate work differently by account, segment, or geography. A partner may carry adoption as well as implementation. The point is to prevent responsibility from disappearing between valid scopes.

Follow one seam end to end

Suppose pre-sales demonstrates an agent against a narrow path. The specialist program provides guidance for identity, controls, and lifecycle. Custom connectors and workflow changes sit outside that guidance, so a partner implements them. The client approves production and supplies an operating owner. Customer success later reviews adoption while a product limitation requires vendor escalation.

At each transition, an assumption can be lost. The demonstration may have used clean inputs. Guidance may identify a control without assigning the engineer who implements it. The partner may release a connector without owning ongoing incidents. Customer success may observe low adoption without authority to change the workflow. Product may receive a feature request without the evaluation evidence needed to reproduce it.

No single team failed. The handoff system did.

Give each boundary a packet

Every material handoff should carry a small boundary packet:

• scope and explicit exclusions;
• required inputs and their owners;
• output artifact and acceptance condition;
• receiving owner and decision right;
• production or support boundary;
• escalation path and required evidence.

This packet can be a section of the deployment charter rather than a new bureaucracy. Its purpose is to make loss visible. “Introduced the teams” is not an accepted handoff condition.

Acceptance should be observable. The receiving owner should confirm that inputs arrived, exclusions are understood, access is approved, and the next decision can be made. If the packet exposes an unowned responsibility, the handoff pauses while the parties route it. That pause is cheaper than discovering the gap during release or incident response.

Audit the post-sale responsibilities

Before approving the delivery model, trace five responsibilities:

Qualification: who revalidates the workflow, users, data, dependencies, and route after commercial discovery?

Workflow adaptation: who maps exceptions and makes business decisions the vendor cannot make for the client?

Production: who owns code, connectors, identity, environments, evaluation, release, observability, incidents, and change control?

Adoption and operation: who changes behavior after go-live and manages the workflow as models, policies, and users change?

Feedback: what evidence returns to product, through whom, under what data rights, and with which response owner?

The answer can involve several teams. It cannot be nobody.

Use the map in selection and design

Buyers should replace “Do you have FDEs?” with more specific questions. Which team qualifies custom delivery? What implementation does the guidance program exclude? Who operates the released system? Who owns adoption? How do field findings reach product?

Vendor leaders can use the same map to design intake, artifacts, decision rights, and escalation across post-sale teams. Practitioners can use it to translate FDE capability into incumbent roles such as solution architecture, specialist engineering, professional services, customer transformation, or partner delivery.

The career implication is useful; the buyer implication is urgent. A clear scope boundary allows work to be assigned early. An unowned boundary waits until production to announce itself.

Before the contract becomes a deployment problem, put a name beside every post-sale responsibility and require an accepted packet at every handoff. Recheck the map whenever the vendor, partner, or client scope changes.