Deal with sessions, authentication, caching, templating, logging etc here. Fires up an instance of the App and keeps it around for the duration of the life of the Web instance. I actually have an API in here that looks like what you'd expect in most other web apps. It does the validation / error handling etc. In terms of manipluating the data, I'm not a total purist - the API is allowed to load up the SQLA models and make changes. If there's a more complex operation going on though, it will live inside the next layer down.
Deal with remote services / data models / db connection. I guess on the outside you might call this a "service layer". A surprisingly large amount of this is data persistance management. The model I use is to put the data access stuff just off to the side at the top level of the app. Nothing in here knows anything about things like web frameworks. This is important. In other places in the system, this same App is used by RQ (worker instances taking on work via a redis queue). There's another web app that uses it for administrative tasks. I can boot it up to work with it in ipython (I do this a lot). Oh, and I don't manage the db life-cycle here. Whichever layer sits above this determines when it's ok to commit transactions. If something goes wrong here we raise app specific expections - the layer above can handle those and relay them as appropriate.
In the very core I have "pure" algorithmic stuff (for context - http://www.countfire.com is effectively an image recognition app). Really this is just one component that the App happens to be using. If the App wants to talk to this, it needs to create the data structures that the core defines. At various borders I often have mappings from the objects in the current local world to versions for the created to talk to the layer below (ps I like namedtuples).
It's a lot more complex than all this, each of these layers has more sub layers etc. And really, what I've called the Core is a sublayer of the App (in my case there's a well definied algorithmic chunk that I think of as the core so it's in its own package - it stands alone as its own library).
There's no real way of knowing where you'll draw lines between the layers when you start but I have a few rules. Any bit of code should be given the bare minimum of data required to do its work. At borders map local data to data for the next layer. Make sure the stuff going into the current layer is really there because it needs to be there. Be a pragmatist - things will change, you'll pull stuff out into submodules. By following the other rules hopefully refactoring won't be too painful.