"Duplex seems trained against this corpus. The end game would be for the business to run something like duplex on the other side, and you’d have duplex talking to duplex."
So, you would just have an automated booking system API which is better handled by not placing calls as its form of communication. Right?
This is an API that requires no computer on the user's end and is portable across different implementations from different companies.
It's not ideal. Actual standardized APIs are better. But, uh, have you ever worked with industry standard APIs? I have, and standardized is not how I would describe them.
I still think there's a need for standardized APIs in this situation. At some point, the context constraints mentioned in the blog post have to get translated into some action with parameters. I'm guessing that action will be API calls to other Google products behind the Duplex Google Assistant UX.
"Ok Google, can you reschedule my Dr. Appointment this Friday for next week? I have a conflict." -> calls the Dr and reschedules -> adapts result to rebooking action with partners (ie, an api call to your Google calendar) -> applies action and responds to you.
There is still quite a bit missing from this to be a useful AI product. It's getting really close though. I can't wait until this makes it into Google Assistant and it can call a restaurant to ask about gluten free options while I'm driving.
You're absolutely right! There's a huge need for standardized APIs for interacting with outside systems for this use-case. In your example, your doctor's office.
In practical terms, there may be some minor issues such as incompatible multiple implementations and adoption costs. But that's made much easier to handle by a very small number of expected consumer systems.
As for interactions with end-result partners, well. I've worked with standards designed to represent such highly general cases (xcbl and cxml). They're invariably rife with interoperability problems and other issues arising from overly broad standards. These tend to not get better over time as much as one might hope, as it's not easy to continuously update standards at a reasonable speed across N target types of partners. Keeping up with how usage evolves is never easy.
The best approaches to this that I've seen in use are those that focus on providing a vehicle for arbitrary data for delivery to the app - like HTTP or TCP. Getting more specific is the route to madness. Which, unfortunately, is probably precisely the bit you'd most like standards around.
You're completely right. There's a very real and very important need for standards here. There just might be some issues worth mentioning that might arise from the attempt to create and rely on them.
This is my initial reaction too, but APIs need work for coding, integration, testing, make sure data is sent in the right format, etc, while voice-robot-to-voice-robot will just work out of the box.
You're completely abstracting away all the coding, integration, testing, and "data formatting" (read: grammar) involved in Duplex, which seems to be much more complex than an REST API.
So, you would just have an automated booking system API which is better handled by not placing calls as its form of communication. Right?