I'm not saying that tenured faculty working on these projects is the norm; that's not at all the case. It's just that the few instances were I know of someone successfully building and maintaining a large low-level library like this on their own come from dedicated academics who can de-facto make it the majority of their job. The best example I know of being Tim Davis' SuiteSparse C library for sparse matrix algebra.
Aside from that, the market failure I foresee for your project is the following: Say you keep building this out and write a fantastic, state of the art general purpose NLP python library. Now an a academic like myself comes along and forks the AGPL version of your repository, contributing additional functionality to the parts of the pipeline I am most familiar with. You cannot re-incorporate my work into your commercial license (unless I sign those rights away, which I won't), so now you're stuck trying to license an inferior version of my fork. Meanwhile, since mine truly is just open source, my version can freely accept both bug fixes and added functionality from one-off contributors who are using said fork. Better yet, unless you change your business model, I can continue to re-fold in any changes you make upstream, as well as include parts of other GPL libraries that build up in the intervening time.
Now, I'm not saying this is a perfect argument. Perhaps enough people are still interested in paying you for a a commercial version of the original software, but I think in the long run as the two version diverge that's unlikely to generate sufficient revenue for you.
My thinking is that there will be commercial contexts where an AGPL license is a non-starter --- it's incompatible with the business model. If so, I think it makes sense for them to buy a commercial license from me, even if it lacks features in your fork. If they can't use AGPL code, your fork may as well not exist, except as this tantalizing something-I-can-never-have that makes the main library look worse.
I'd also note that you gain absolutely nothing from maintaining your separate fork, other than the principle of the thing. I'm compelled to distribute the code under the AGPL, just as you are. If your features are compelling you could instead negotiate with me for a cut of the license fee.
Aside from that, the market failure I foresee for your project is the following: Say you keep building this out and write a fantastic, state of the art general purpose NLP python library. Now an a academic like myself comes along and forks the AGPL version of your repository, contributing additional functionality to the parts of the pipeline I am most familiar with. You cannot re-incorporate my work into your commercial license (unless I sign those rights away, which I won't), so now you're stuck trying to license an inferior version of my fork. Meanwhile, since mine truly is just open source, my version can freely accept both bug fixes and added functionality from one-off contributors who are using said fork. Better yet, unless you change your business model, I can continue to re-fold in any changes you make upstream, as well as include parts of other GPL libraries that build up in the intervening time.
Now, I'm not saying this is a perfect argument. Perhaps enough people are still interested in paying you for a a commercial version of the original software, but I think in the long run as the two version diverge that's unlikely to generate sufficient revenue for you.