Early iterations, especially the 1st, will contain or should at least plan for architectural spikes, which include a certain amount of discovery time and maybe some architectural prototyping.
Like you said, generally, there are structural requirements which may not mean much to the stakeholder / customer, but are required to form a strong platform or pattern orientation. You cannot get around this as you can't start building B until A is complete.
Part of the Agile approach is to have the customer close so documentation is not needed because all you need to do is pick up the phone / send email, and it's expected. The customers expectations should be set appropriately and any work completed should be very terse and NEEDED. No gold plating, no "You might need it", etc.. Build what you need in A to move onto B.
Depending on how you're attacking the project, you may only build out the required foundation in order to complete a certain module, so during the sprint planning meeting you would lay out the plans for the current sprint based on the priorities set forth by the customer, depending on what is needed for that sprint, there may be some foundational requirements, so that's what goes into sprint 1. After the 1st sprint is complete and A has been built and then plan to complete B.
If you've agreed on a timeline with the customer, as long as you're going to meet that agreement, the customer probably won't care what you do 1st or 2nd. You could always show them the unit test results, but if you say we'll have something for you to see after sprint 2 (or 3), and you deliver, it will set a strong precedence. Customers are expected to be reasonable as much as developers are and both are working towards the same goal. A completed project which meets the needs of the customer and works as expected. So worrying that there's nothing to see after sprint 1 is a moot point because the customer just wants to make sure that after sprint 20, the project will be done(-ish).