I'll make an assumption here, but it seems to me that you are thinking about your Agile project from a traditional project management perspective, where you focus on layers of work or on work packages that you need to prepare, plan, and then build, with each piece having to be accounted for in the correct place. You are focusing on project work basically. With Agile there is a different mindset, one that places greater importance on the product being built and on delivering value.
If that requires business analyses, architecture pages, functional and technical specifications, etc, then so be it. If not, then not. If some, then some. In other words, each Agile team within its context and domain, decides how to manage things, including documentation or specifications, but truly Agile teams will tend not to have such separations between the different parts of what they are building. As another answer mentions this can cause a separation and introduce obstacles to communication and collaboration while people are busy updating "their documents" and throwing them above the fence to someone else, back and forth.
In Agile, you choose an incremental and iterative approach and build small features that need to contain all things needed for people to understand what they need to build. And these things tend to stick together with the feature instead of being expressed as sections of different larger specification documents. In Agile you build products from items in a product backlog, not from specifications (at least not heavyweight upfront written specifications as traditional project management is accustomed to).
So if you are looking for a standard project structure, then at best that will be a properly refined and maintained product backlog and people work from the top of that. Otherwise, there isn't a standard one. Agile teams are self-organizing and self-managing and decide for themselves how to structure things in order to reach their goals.