◇ Could this help me?
Yes for the principle, treating the rest as vendor marketing. The transferable idea is sound and predates this product: data is only usable by an agent if its meaning is catalogued alongside it, and tagging on arrival rather than when someone finally writes a pipeline is the difference between a store that can be queried and a store that has to be excavated. That is worth internalizing whatever platform is in use. Everything else here is a launch pitch, so the claims about zero manual data engineering and autonomous pipeline construction should be checked against the actual documentation and someone else's experience rather than the keynote. General practice for the catalog-first principle, and the row is worth keeping for that rather than for the product.
I want my data to be usable by an assistant without rediscovering what it means every time. For the data sources I describe below, help me work out what metadata would need to exist for each one so that meaning travels with the data: what each table or file represents, who owns it, how fresh it is, and what it must not be used for. Then tell me which of my sources currently have none of that, and propose the smallest catalog I could maintain by hand before considering any platform. Be honest about where a vendor product would genuinely help and where it would just move the same missing information somewhere else.