A conversational AI feature can look simple from the outside: collect a question, generate a response, and render it nicely. In practice, the difficult work is defining a reliable contract between the model, the product, and the user.
I recently explored these problems while building an online AI tarot experience. The domain is unusual, but the engineering lessons transfer to many recommendation, coaching, and narrative products.
1. Treat the model output as data
Free-form text is quick to prototype but difficult to build around. The interface may need a card name, orientation, short meaning, detailed interpretation, and a final reflection prompt. If those pieces arrive in arbitrary order, the frontend becomes a parser full of edge cases.
A more reliable approach is to define a compact structured response with a cards array, a synthesis field, and a reflection question. Each card object can contain name, orientation, summary, and interpretation. Validate this structure before rendering. A schema does not guarantee that the content is good, but it turns malformed output into a visible, recoverable state instead of a mysterious UI failure.
2. Separate interpretation from certainty
Narrative products can accidentally sound more authoritative than intended. The prompt should distinguish reflective language from factual prediction. Phrases such as "this may point to" or "consider whether" leave room for the user to think. Claims about guaranteed outcomes do not.
This is partly a writing problem and partly a product safety problem. The system prompt, examples, and post-generation checks should all reinforce the same boundary.
3. Give every position a job
A three-card reading becomes easier to understand when the positions are defined before generation. Situation, tension, and next step is a useful structure. It helps the model build a sequence instead of producing three disconnected mini-essays. It also gives the UI meaningful labels and makes retries more deterministic.
4. Design fallbacks before polishing animations
Model calls fail, time out, or return content that does not validate. A useful fallback plan includes:
- a visible loading state with a realistic expectation
- one bounded retry for transient failures
- schema validation before display
- a safe generic message when the reading cannot be completed
- request IDs in logs for debugging
The fallback should preserve the user question when possible. Asking someone to re-enter an emotionally meaningful prompt because of an avoidable UI reset is a poor experience.
5. Evaluate tone with examples, not adjectives
Instructions like "be warm" or "be insightful" are too vague to test. A small evaluation set is more useful. Include ambiguous questions, short prompts, emotionally charged topics, and prompts that request certainty. Review whether the response stays respectful, avoids repetition, acknowledges uncertainty, and ends with a useful reflection.
A simple rubric can be scored manually at first. Consistency across twenty representative cases is more informative than one impressive demo.
6. Let the product explain itself
People need to know what the experience can and cannot do. Clear onboarding, example questions, and concise disclaimers reduce both confusion and prompt variance. The live AI Tarot experience is one place where I am applying these ideas and observing how structure and tone affect the final interaction.
Closing thought
The most reusable lesson is that prompt engineering is only one layer. Good AI product behavior comes from the whole system: input design, response contracts, validation, fallbacks, evaluation, and honest UX. When those pieces agree with each other, even a highly subjective experience becomes easier to build, test, and improve.
Top comments (0)