This generalising, abstract thing is distracting you. Agile will teach you very quickly to become pragmatic. There is more to be learnt by taking on problems in small parts that are highly specific. Once you grok each part, the repetition of this process will help you learn the process and build domain knowledge at the same time, thus progressing you to bigger and bigger fractions of the whole as you rack up more and more of these small pieces.
You could have described your "large back-end system with a single entry-point" far more exactly without making an analogy.
I think reading into your "vertical slice" narrative, you're attempting to create something like an MVP epic to begin with. You have my applause for this intention. It's very characteristic of a lean startup and something I've also done in the past.
The purpose of an MVP is learning: to test the riskiest assumptions ("de-risk" them) and validate those core elements. So the next step is to break this large idea down into the assumptions. Since this is so freaking vague and hypothetical, I'm going to make some assumptions of my own for the purpose of demonstrating this "breaking down" process. Here we go:
- The value part of As a user, I want to know to the meaning of life, so that I know why I exist is "so that I know why I exist".
- "so that I know why I exist" answers the broad and very 'root' philosophical question "Why do I exist?"
- If "Deep Thought" can answer the root question "Why do I exist?", it's logical to assume it can answer far more derived and specific questions, like for example "What is 1 + 1?"
- Can we define a vertical slice as "As a user, I want to compute basic arithmetic, so I can validate my arithmetic understanding"? (or something similarly nonsensical)
- Maybe it's not a complete vertical slice of all the complex internals for the root computation, however it will test out the query input system, the result/output delivery system and some arbitrary infrastructure to model the capture of a query/request and some of the processing pipeline (maybe)
- So let's say our epic is As a user, I want to compute basic arithmetic, so I can validate my arithmetic understanding and our first story is As a user, I want to evaluate 1 + 1, so I can verify basic arithmetic. Boom! you now have something concrete and explicit you can even write an end-to-end test for (maybe)
You may still want to break this story down into user flows around the input, output, etc as you discover more. But this discovery process is facilitated by the discussion you have like this (these bullet points). As you force yourself to brainstorm and cut things up, you discover more about the domain and details materialise. Things become concrete and explicit, or at least you force them to.
By the way, this is also wrong: "We can't deliver anything of use to the user until the entire back-end system is complete".
Just like a business can build a facade to an automated system by using the concierge service technique, you too can do the same and still deliver value. If your "1 + 1" story eventuates and you have some sort of automated test that asserts the result "2", you can implement this using static code to pass the test right? (Think TDD.) It doesn't even need to use a binary operator initially.
You can totally deploy this to production and show the 'user' how the product (Deep Thought) can reason and produce a result from a very specific query. You don't have to say it's "hard coded". You're trying to test assumptions in an agile manner and capture the feedback in a tight loop.
This is what agile and lean are all about: capturing learning as fast as possible. This is made possible by as small a batch size as possible. The result of this process is as little waste as possible.