Bidirectional Interactivity Limitations of AI Tools
You’ve probably seen the amazing work of Rewind.ai and Fabric.so. Here’s why I view these tools as temporary fads and don't think these tools will last very long.
Limitations of existing solutions
With the rise of artificial intelligence, we see the rise of “omniscient assistants”. The idea usually revolves around information gathering via API connections, scraping, or mass-collection (screen recording and/or wearing a device that collects large amounts of data regarding personal activity). After training AI on this data, they’re able to have conversations about their personal history. We also see this with tools around organizational workspaces. “We’ll scrape your Slack and you can ask us anything, and we can summarize stuff!” The concepts of an omniscient assistant are fantastic, like a personal Jarvis from Iron Man, however I think there are some problems preventing these tools from becoming much more than they currently are.
Problem One
First, data-interaction is unidirectional in the sense that new data cannot easily be written to the parsed sources from that assistant, requiring the user to either use the source interface to create new information, or connect the assistant to the source via API connection.
Problem Two
Another issue is that the data collection phase may not be accurate. For example, data pertaining to a topic may not be entirely visible to the collector. What if you have an event invitation in your messaging app, but your collector has only “seen” your calendar? Or what if an interpretation error occurs between the collection, parsing, and training steps that leads to incorrect information inside your assistant?
Problem Three
Additionally, the legality is questionable as your assistant has to browse, collect and store many pieces of third-party information in order to train the AI. One addition to a terms of service, and you may have a lawsuit to deal with. Regarding that last point, organizations aren’t necessarily keen on giving away their data. For many organizations, data is gold, and those organizations will go to extreme lengths to protect that ownership of that data. We’ve seen methods to prevent large-scale data collection before via complex DOM structures to obfuscate information, rate-limiting, bot detection, CAPTCHAs, and more. Many organizations will be incentivized to ensure that these tools don’t work, especially organizations that wish to keep users inside their own ecosystem, particularly if they have their own AI product.
To conclude the coverage of the existing ecosystem, there really is no practical solution for the problems outlined above. The success of the software will always be dependent on the cooperation of the entities that control the user data, which will soon realize they are not incentivized to do so. If even one major player starts to work against these tools, which I predict will happen sooner rather than later, then the product success will diminish over time. Lastly, and perhaps most importantly, any third-party connection requiring the input of an API key is a bad user experience and restricts adoption by the masses. Perhaps smoother experiences can exist, but again, these products rely on third-party features and benevolence.
Alternative Approach
The demand for these tools is clear. We’ve seen huge public support for projects like Rewind.ai and Fabric.so. Both do what was described above. However, I think their success is fleeting, with flaws that highlight potential for a more powerful assistant. I believe a decentralized approach to app development will overcome these hurdles by enabling full access to reading and writing without inhibition. Once we remove our dependency on third parties and the power of data is returned to users, true omniscient assistants will be able to succeed.