Recently I partecipated in a discussion on the topic above; here are my thoughts.
Documentation has a big flaw: it gets out of date. And it has a cost. And is subject to interpretation, anyway. Face to face communication is a very good option, provided that you have access to the right people when you need them, as what is unclear can always be further discussed. There are many techniques that help, as active listening and many others.
But the real trick that avoids information loss (at least it minimizes the risks) is the continuous feedback that the team gets by the customer, typical in agile methods. In Scrum, e.g., at the end of each sprint (normally 30 days) the team holds a demo in which a working product is shown to the product owner (a "power proxy" for the customer), and that's where eventual misunderstandings pop up.
Another technique is having the customer write his own acceptance tests, using frameworks like FitNesse. That's also a very good documentation at system level, because tests describe exactly how the customer expects the system to behave. At code level, i.e. for developers, automated tests are the best documentation you can get, as they exactly describe how different pieces of software behave.
What level of documentation can be expected? it depends, and it's not only about how agile your process is. If defects in software could cause loss of lives you'll probably have a higher process ceremony, which means more and more detailed documentation, if software defects could only cause loss of comfort or discretionary money it's a whole different story.