AI、エージェント型プラットフォーム、広がるカスタマイズ問題

The question of this chapter

AI has made it easier to build code and highly customizable software. Does that mean every AI company needs a forward-deployed engineering (FDE) team?

The speaker is not presenting the simple conclusion that “AI means FDE is necessary.” In the speaker’s personal hypothesis, as software becomes more flexible and customers have more work to understand and implement it themselves, engineers who help with implementation close to the customer may become more valuable.

AI changes more than development speed

The speaker first explains that AI has made it easier to write code. As a result, it has also become easier to build more sophisticated software that can be changed for each customer.

The important point here is that AI may do more than simply make engineers work faster. Software builders can make more changes for each customer. As a result, the customer who buys the product may also take on more responsibility for understanding its capabilities and configuring and implementing them for its own work.

This creates the following causal chain.

1. AI makes code generation easier.
2. It becomes easier to build software that can be changed substantially for each customer.
3. The way to use and implement the product becomes more complex for each customer.
4. It becomes harder for customers to realize value by themselves.
5. Customer-facing engineers who understand the customer’s situation while implementing the solution may become more important.

The speaker clearly presents this explanation as a “personal hypothesis.” It is not a conclusion proven as a fact in the talk. The talk also provides no supporting data for broad claims such as “almost every platform will become agentic.”

What is an agentic platform?

In this talk, “agentic” does not simply refer to an external, general definition. Here it points toward software that can carry out some amount of work or combine several processes, rather than waiting for one human action at a time.

In the speaker’s argument, an agentic platform leaves more room for changes that fit the customer’s work. The customer is not merely using one finished, fixed application. Instead, it is assembling behavior and workflows around its data, operations, and methods of making decisions.

Here, we need to distinguish configurable software from software that can be developed upon.

• Configurable software changes fields or rules within a set of provided options.
• A developable platform uses components and data to create an application or flow of operations suited to the customer.

Changing the notification time in a settings screen is an example of configuration. By contrast, building a system that gathers information from several internal systems and advances decisions according to an insurance-review process requires deeper implementation. In the latter case, even understanding what should be built may be difficult for the customer.

The limits of “leaving implementation to the customer”

The problem the speaker identifies is leaving the product’s success entirely to the customer’s implementation. It may work if the customer is technically knowledgeable and has enough time and people. But not every customer has those conditions.

This becomes especially important when moving upmarket into the enterprise market or expanding the product into other industries or use cases, because customers’ backgrounds become more diverse. Knowing the product’s features does not necessarily mean knowing how to fit them into one’s own operations. As the product’s possibilities expand, someone may need to explain and implement not only “what it can do” but also “how to use it to create value here.”

Three kinds of market expansion

The speaker explains that implementation problems can appear during the following kinds of market expansion.

• Upmarket: Moving toward larger companies or customers with higher demands.
• Horizontal expansion: Extending a similar product to other industries and a wider variety of customers.
• Vertical expansion: Going deeper into the operations of a specific industry.

For example, even if a development-support product was first used only by a technical department, selling it across a large enterprise increases the number of departments and operations involved. Expanding into another industry changes the terms and procedures used in that industry. Going deep in one industry requires adapting to its distinctive judgments and rules.

These are different directions of expansion. In each case, however, customers may find it harder to implement the product within their own reality. This is where a role like FDE becomes relevant: it understands the problem together with the customer and builds a solution on the platform.

The conditions for using FDE still matter in the AI era

After hearing this, it may be tempting to think, “If it is an AI product, we should immediately create an FDE team.” But that is not the talk’s claim.

The FDE decision described in the earlier chapters has two conditions.

1. The organization needs to sell something technically complex, where customer-specific implementation matters, to buyers who are not technically knowledgeable.
2. It needs to have, or be willing to invest in, a shared platform and reusable components that let engineers build customer-facing solutions.

Even if AI makes customization easier, these two conditions are not automatically satisfied. For example, if developers can use an AI tool themselves and easily finish both configuration and implementation, developer engagement or a normal SaaS sales model may fit better. FDE is not something to adopt simply because it is fashionable.

Example: deploying an AI agent

The following is a teacher-created example to help explain the speaker’s claim.

Suppose a company offers an AI agent for examining documents for insurance companies. The product can read documents, compare them with internal data, ask questions to staff, and record review results. However, each insurance company has different document formats, approvers, exception handling, and retention rules.

In this case, AI’s ability to create code is helpful. Even so, work remains: understanding the insurer’s operations, deciding which data to use and which decisions to return to humans, and assembling the result into an actual workflow. If the buyer cannot carry out that implementation alone, a customer-facing engineer may be able to provide value.

By contrast, FDE may not be necessary if users can deploy the product simply by choosing a few items on a screen and no deep customer-specific development is needed. This example shows that the decision depends not on whether AI is present, but on the product’s complexity, the technical ability of the buyer and user, and the depth of implementation.

Industry-specific agents and general platforms

The speaker also asks listeners to notice the difference between a general platform and an agent specialized for an industry such as insurance or law. Creating an agent that immediately supports work in one industry is not the same as providing a foundation that many customers can build on for their own purposes.

An industry-specific product may contain deeper knowledge of that industry’s terms and procedures, but its scope may be narrower. A general platform can support more use cases, but customers may have more design work to adapt it to their own operations. The hypothesis of this chapter is that, in the latter case, FDE support for customer implementation is more likely to become valuable.

The historical connection and the limits of this chapter

The speaker also touches on the idea that Palantir entered the market around 2004 or 2005. However, this is not stated as an exact date. The historical explanation here does not mean copying the earlier FDE model directly into the AI era.

The change the speaker emphasizes is the spread of customizable software. The number of products is not the only thing increasing; the range of forms in which customers can realize value is also expanding. A business question is whether customers will fill that range themselves or whether the product company will fill it together with customer-facing engineers.

However, the talk provides no data on the success rate of FDE for AI products or on the required team size. Therefore, what you should learn here is not a settled law of the industry, but a way to evaluate FDE. In other words, check whether AI-driven customization is widening the gap between customers’ understanding and their ability to implement, and then consider whether you can deliver customer outcomes using a shared platform.

At the end of this chapter, the talk moves to audience questions and applause. There is no further specific answer in the content around 690–794 seconds.

Source: