The most common reason a capable platform produces nothing is not technical. It is that the two groups who needed to build it together never had the same picture of the work.
We see businesses with everything they need already bought. The licences are live, the agent tooling is available and the platform is genuinely capable. Twelve months later almost nothing is in daily use.
It stalls because operations is too busy to give the time, technology understands the platform but not the lay of the land in the operation, and so the product comes out close but not on point. Adoption stays low and the licence renews anyway. The gap between those two groups is where the value is, and it needs people who can stand in it.
It rarely looks like failure, which is part of the problem. It looks like this.
The business has bought a serious platform. Foundry, or Vertex AI, or the equivalent from whichever provider the business already stands on. The capability is real and the licence cost is already sunk. A small internal team has built two or three things. There was a good demonstration. Somebody senior was impressed.
A year on, one of those things is used by four people, one is used by nobody and the third was quietly turned off. Nobody calls it a failure because nothing broke. The renewal goes through. The next initiative is announced.
Three causes, and it is almost always all three at once rather than one of them.
Not usage in the first fortnight, which measures curiosity. Usage in month four, by people who were not in the room when it was built, without anybody chasing them.
If that number is low, the honest reading is almost never that people are resistant to change. It is that the thing does not fit the work well enough to be worth the switch. People in a busy operation are ruthless about this and they are usually right. A system that genuinely saves them an hour gets adopted without a campaign.
What sits between the two groups is not a project manager and it is not a business analyst writing requirements. Both of those pass messages between people who do not share a picture. What is needed is a small number of people who hold both pictures themselves and can build.
Concretely, that means someone who can sit with a desk for two days and see what is actually happening, name what it costs and then go and build the thing that week rather than write it up for somebody else to build next quarter. The loop has to be short enough that the operation gets a version back while it still remembers the conversation.
In recruitment, the difference between a system that lands and one that does not is usually whether the people building it understand which numbers the business actually runs on. That is not learnable in a discovery workshop. It is the vocabulary of the operation:
Anyone who knows those can tell within a day which automation would change a number and which would produce a pleasant demonstration. Anyone who does not is guessing, however good the platform is.
The working arrangement matters as much as the skill. Forward deployed means the engineers sit with the operation rather than receiving a specification from it. They use the systems the business already runs. They build inside the platform the business already owns, in its own account, rather than introducing a new one that has to be justified later.
That last point is worth stressing. If a business has already bought a capable platform, the job is to make that investment produce something, not to sell a parallel stack alongside it. Most of the time the tooling was never the problem.
The technology is rarely the constraint now. The constraint is the distance between people who know what the platform can do and people who know what the business needs it to do, and that distance is closed by standing in it rather than by writing across it.