Your client has identified a business case that they believe is worth spending money on: Creation of a mobile app. The client has engaged with the Advertising company who has probably promised the moon. Then, the Advertising company sub contracted the software development project to your software development firm.
Unless your client has tasked strong business leaders to handle this project, there's a good chance that the client doesn't understand what they want, much less articulated that to the Advertising company. If you "just do what the Advertising company says", you may get your paycheck for this project, but you could also be setting yourself up for failure.
This situation is one of the areas with Agile software development can be very effective. Here is how I would approach it.
Go to your point of contact at the Advertising company and explain to them, "The better we help the client understand what they want, the more happy they will be with the product we deliver. To make sure that we are delivering the right product, our software developers (or a representative from our software developers) need to engage directly with the client. Both your company and mine will have a more satisfied customer if we can approach this project using Agile software development principles. The first step towards that is to establish a product owner team that consists of you (the Advertising company), the relevant decision makers from the client, and my software development team. The product owner team should plan for a long first meeting to initially establish and prioritize the backlog, then we should have (1, 2, or 3) week sprints to present what we've developed and continue to refine the backlog."
When you have your first product owners team meeting, you have to quickly educate the team on why it is important they spend time doing this and what that team's purpose is: create and prioritize the backlog. In other words, you want the product owners team to dream up every feature that they could possibly want. The team can think in term of "epics" or big ideas. Then, get the product owner team to prioritize their epics. Once the client has identified a number of epics AND prioritized them, then let your software team can start to dissect the epics that were ranked the highest. Don't let your technical team get into details - or "how we are going to accomplish this" - too soon. In the beginning, while you are still creating your backlog, keep it high level. Once your backlog is made, then you can start to get down into the weeds - but only for the highest rank epics that you are going to tackle in the next sprint or two.
Tips and References
Likewise, a tip from my experience, as you begin the project, focus on UI first. Non-coders can't visualize what it will look like. It's better to show them a non-functioning UI than no UI at all.
When you are contracting for a company, implementing Agile using SCRUM tactics has been the most effective for me (versus Kanban or waterfall). I love making people go through this series just so they can get the basics. Then we tweak it from there...