The Last Mile of Enterprise AI: The Bottleneck Isn't the Model, It's Implementation

When people talk about AI inside a company, attention tends to drift toward the model: parameters, compute, benchmark scores. But pull the camera back, and a working model depends on an entire chain—semiconductors, data centers, the power that feeds those data centers, and the storage batteries that hold that power. Only when all of it is in place does a strong model actually run.

A model that runs, however, is not the same as AI that runs inside a business. In this session, the speaker from SoftBank placed his company at the last link in that chain: implementation. A model has to be built into society and into companies, and it has to run safely. Until that link is finished, all the investment before it is only a half-finished product.

A chain from semiconductors to implementation that cannot be skipped

The speaker spent a little time on the infrastructure stack: semiconductors first, then data centers, then power and storage. The ordering is not new, but it explains something often overlooked—competition in AI is not decided at a single layer but across the whole supply chain. If any layer is missing, the model never reaches the ground.

At the far end of that chain sits "implementation": connecting model capabilities to concrete work so they produce real results. That, the speaker said, is where his company positions itself.

Not one chatbot, but agents across every department

What they describe is not "give every employee a chat window." It is AI agents introduced into business units, the back office, sales, and engineering. The agents don't work alone; they coordinate. One receives information, another picks up the next step.

The division of labor shifts with them. AI takes on reasoning and execution; people concentrate on decisions. The speaker's estimate: about half of an employee's daily work can be handled by agents.

What matters here is not the number "half" but the placement: AI goes inside the workflow, not beside it as an assistant. When agents coordinate across departments, permissions, data, and boundaries of responsibility all have to be redesigned. That leads straight to the next question.

The more autonomous the agent, the earlier security has to come

In June, the company announced a security service focused on defending against attacks on AI. The reasoning is blunt: if an agent is hacked, it will do things it shouldn't. At that point, every efficiency gain that came before is wiped out.

So the order is defense first, rollout second—especially for Japan's critical infrastructure. Behind that order is a cost structure rarely mentioned on slides: the more autonomous the agent, the more entry points it exposes. Letting an agent read data, operate systems, and act on someone's behalf widens the attack surface considerably.

FDE: find the real problem first, then talk architecture

So how does implementation actually proceed? The process the speaker described is unremarkable: identify the customer's real problem, define the technical scope, design the architecture, build a prototype, take it to production. It is an ordinary development sequence; the hard part is not skipping any step.

One role comes up again and again in that process: the FDE, or Forward Deployed Engineer. Palantir is said to have pioneered the role, and many companies are now adopting it; SoftBank has its own FDE team. An FDE is not a consultant who only gives advice. An FDE is an engineer who works with their own hands and ships something.

The company divides FDE capability into five levels and focuses on a few of them. Level one: understand the customer's problem, define the technical scope even when the situation is unclear, face the customer directly, and carry a prototype all the way into production. Level four: be more hands-on than others and translate between technology, customer requirements, and product. The most important is level three—the judgment to design systems, implement them, and move them into production.

What does that judgment mean in practice? It means judging, in different business domains, whether a given architecture will run and run safely once installed. It means implementing in open-source components and unfamiliar language environments, and judging whether that implementation is safe. Then taking it to production. The speaker called this capability very rare, which is why the FDE unit is small and elite.

Legacy systems are the floor the agents stand on

FDEs alone are not enough, though. Many Japanese companies—SoftBank included—run systems built up over many years. Turning all of that into AI at once is extremely difficult.

The speaker listed a few typical conditions: still on mainframes, code in COBOL, not on GitHub, no specifications, data scattered everywhere. On that foundation, agents simply cannot run. So the first work is cleanup such as cloud lift: moving systems onto a platform an agent can safely take over.

To do that, they also created new job types: the planning function that TPMs used to own and the operations function that SREs used to own, each redefined as an "AI version," then teamed with FDEs. The detail says something: implementation is not the heroics of a few engineers. It is a re-arrangement of roles and collaboration.

150 requests in six weeks, finished by one person in hours

The speaker played a screen recording he had made himself: about 150 bugs and feature requests accumulated over six weeks.

The old loop: fix a bug, deploy, review, test, roll back when something is wrong, think about whether another revision is worth it, confirm, deploy again—over and over. Now one person iterates in roughly one-hour rounds and finishes the whole batch in five to eight hours.

What supports that speed is a loop of verify, implement, improve. Even where no specification exists at all, they first write the definition of verification and the constraints into an instruction file for the agent, then let the agent keep implementing. Write down what counts as correct and what must not be done before chasing speed. That order is what turns speed into quality.

Enterprise requirements do not disappear, of course. Production design, security, answer quality, governance, and availability all have to be considered as the work proceeds. Otherwise the demo is fast and the release is still slow.

Implementation moves the organization, not just the model

At the end, the speaker said he wanted to move forward together with enterprise teams, and mentioned that they are hiring engineers. Back to the chain from the beginning: semiconductors, data centers, power, and storage determine whether a model can exist. Implementation determines whether a model can become a way of working in society. The second is harder, because what changes is not one model but systems, permissions, job types, and where people sit in the decision-making process.