I still feel like having that CLI be a frontend into a library that could then be reused by arbitrary GUI frontends as well would achieve basically the same thing.
In my mind, an application is basically a bunch of state, various ways of mutating or accessing that state, and then logic to present that state to the user. The ideal way to structure this seems like it would be putting the state behind an API that provides endpoints for the valid state transitions and for accessing the state without mutating it; at that point, you can wrap it with whatever interactive wrapper you want (a CLI, a GUI framework, etc.), and all of them will have identical semantics. An agent can use the CLI if that's what makes sense, a technical user with extremely strong opinions on GUI frameworks can wrap the library in the framework of their choice even if you don't provide a pre-built version of it. If anything, this approach seems like it makes even more sense in the agent of LLM coding; five years ago it would not be worth it for me to look at something like this and say "they provide a CLI and a Windows native GUI, but I really want a Qt GUI, so I'll make it myself", but nowadays I can probably just point whatever the best model that's available for free from OpenCode at a library structured like this and get something working without too much manual effort.