"you sold him you knew how to do it, right?"
I never said that. You introduced the software team's prior mastery of the problem domain as a reason that agile was not appropriate to the problem. I didn't assume that -- I was thinking that both sides would have the opinion "we can just ask the human workers how they match these images", not realizing that this is a hard AI problem, or that there is still argument over whether a computer system should try to find one match or just produce a relatively short list of close matches.
I have been through training on almost a dozen different quality management approaches and systems, not all of them software- or even R&D-focused. The one thing I have learned is that there is not one process that is right for all software organizations or projects. I tend to think that there are much better ways to handle uncertainty and change risk than agile. For example, I expect storyboards and mock-ups to be more cost-effective ways to clarify the "known unknowns" than agile's sprint methodology -- which basically says to put something in code, and react to errors. I think both agile and other methodologies require good architectural decisions to avoid costly rework when a requirement unpredictably changes (an "unknown unknown"). Keeping both sides in the loop when assumptions are made or goals change is not an agile-specific process -- it is common sense and basic relationship management.
So that is why I asked you what kind of project agile is good for, and your answer seems to be that it is only good for a kind of blue-sky research that hardly ever happens. Most leading proponents of agile claim that it is good for a much wider problem domain, so I conclude that either you or they are wrong -- and if they are wrong, that speaks loudly to the agile approach itself being wrong.