A startup's language platform became Google's chatbot foundation

The conversation

On 19 September 2016, the founders of a startup called API.AI told their developer community that the company was joining Google. Ilya Gelfenbeyn, the chief executive, wrote in the company's own farewell post that API.AI had launched in 2014, building a platform for conversational interfaces for chatbots, connected cars and smart home devices. The post promised continuity: developers would keep building on the same platform, backed now by, in Gelfenbeyn's words, Google's knowledge, infrastructure and support. Google's own contemporaneous statement was not available during this research; the acquisition is documented here through the acquired company's own words.

What the documents show

The 2016 post establishes only what API.AI said at the time: that it was being acquired, that the platform had existed since 2014, and that the deal was framed as continuity. It does not describe later technical change. For that, Google's current documentation is the relevant source. Google's Dialogflow documentation, retrieved 16 September 2026, states the product now splits into two services: Dialogflow ES, the standard agent type for smaller and simpler agents, and Dialogflow CX, an advanced type for larger or more complex agents. Dialogflow ES's own concept pages define an intent as something that categorizes an end-user's intention for one conversation turn, built from training phrases, meaning example phrases for what a user might say, and entities that dictate how data is extracted from what a user types or says. A fulfillment webhook lets that data reach a developer's own code before a reply is chosen.

The system boundary

An intent-and-entity model draws a boundary around what the software judges: it decides which of a developer's predefined intents a message resembles, and which words fill which slots. Everything past that, including what to look up, what to say back, and whether to escalate, is fulfillment code the developer writes and hosts. Dialogflow does not itself decide business logic; its documentation frames its role as stopping at understanding and handing off a structured result. That division has not changed since API.AI's original pitch, even as the surrounding product, ownership and branding changed substantially.

Where it fails

The clearest limitation is one the sources create by omission: the 2016 farewell post promised continuity, but the platform was later renamed and split into two separate services with separate documentation, a bigger structural change than that post anticipated. A builder relying on an old reference to Dialogflow should check which of the two current services, and which document version, is actually meant.

• Does a given reference to Dialogflow mean the ES or CX agent type, and does that distinction matter for the feature being described?
• Who hosts and maintains the fulfillment webhook, and what happens to a conversation if that endpoint is slow or unavailable?
• How were the original training phrases and entities validated against real user language, rather than the phrasing a developer expected?

None of this is a criticism of the underlying design; an intent classifier paired with a developer-owned fulfillment step is still the pattern most competing platforms describe. A platform's name can outlive several versions of what actually runs behind it.