# Building an AI Tarot Reader: From Random Cards to Context-Aware Reflection > Source: > Published: 2026-08-27 02:53:17+00:00 Drawing a tarot card is easy. Understanding why that card matters to a particular person is the real challenge. Most online tarot experiences follow the same pattern: click a deck, reveal a card, and display a paragraph written in advance. The paragraph may describe the card correctly, but it knows nothing about the person reading it. The same text appears whether someone is thinking about a career change, a difficult relationship, or a creative project. That limitation made me wonder: could an AI system turn a fixed set of tarot symbols into a reading that responds to an individual situation without pretending to know the future? At first glance, an AI tarot reader may sound like a novelty. Look closer, however, and it becomes an interesting product and engineering problem. It combines structured domain knowledge, controlled randomness, narrative synthesis, conversational interfaces, safety design, and subjective evaluation. This article describes how I think such a system should work, what makes it difficult, and where this kind of experience may go next. A tarot deck contains 78 cards. Each card has recognizable themes, visual symbols, traditional interpretations, and possible differences between upright and reversed orientations. A spread adds another layer of structure by assigning a role to each card, such as past, present, future, obstacle, or advice. That makes tarot unusually compatible with language models. The application can provide the facts: The model can then do what language models are good at: connect ideas, identify tensions, explain metaphors, and express an interpretation in natural language. The important distinction is that the AI should not control the facts of the reading. It should not decide which cards appear, silently replace an inconvenient card, or invent a new meaning because it produces a smoother answer. My preferred rule is simple: Let the application control the facts. Let the model handle the interpretation. Before discussing architecture, the product needs an honest definition. I do not think the healthiest version of an AI tarot reader is a machine that claims to predict a fixed future. A language model has no privileged access to future events, another person's private thoughts, or hidden universal truths. Designing the product around those claims would be misleading and potentially harmful. A more useful framing is to treat tarot as a symbolic interface for reflection. An unexpected card can introduce a perspective the user had not considered. A three-card spread can turn an unstructured worry into a sequence. A conversational reader can ask the user to distinguish what they can control from what they cannot. In that model, the reading is valuable not because it delivers certainty, but because it helps the user examine a situation from a new angle. This product definition influences every technical decision that follows: the prompt, the tone, the safety boundaries, the interface, and even the way a reading is evaluated. A useful AI tarot flow can be represented as a small pipeline: ``` User question or topic ↓ Choose a tarot spread ↓ Draw cards in application code ↓ Build structured reading context ↓ Generate an interpretation with an AI reader ↓ Stream the response to the interface ↓ Offer reflection prompts and follow-up conversation ``` Every stage has a separate responsibility. The user provides context. The spread defines the shape of the reading. The draw engine selects the cards. The context builder creates a trusted package of facts. The language model interprets that package. The interface makes the result understandable and gives the user agency over what happens next. Keeping those stages separate makes the system easier to test and prevents the model from becoming an invisible source of truth for the entire product. The first layer is a structured tarot dataset. It should contain more than a card name and a generic paragraph, but it should not send an encyclopedia to the model for every request. A compact reading record might look like this: ``` type ReadingCard = { id: number name: string image: string orientation: "upright" | "reversed" position: { name: string purpose: string } coreMeaning: string keywords: string[] topicMeaning?: string } ``` The canonical dataset can be much richer. It may include symbolism, elements, arcana, numerology, and topic-specific interpretations for love, work, or personal growth. The context builder should select only the fields relevant to the current reading. This improves both quality and cost. The model receives focused information, token usage stays predictable, and irrelevant card material is less likely to distract the interpretation. The cards should be drawn in deterministic application logic rather than inside a prompt. The draw engine is responsible for: The core operation should look conceptually simple: ``` js const cards = drawWithoutReplacement(deck, spread.cardCount) const reading = applyOrientations(cards, reversalProbability) ``` For an entertainment product, ordinary pseudorandomness may be sufficient. A browser or server implementation can also use a cryptographically secure random source when unpredictability and unbiased selection matter. Whichever method is chosen, it should be explicit, testable, and independent from the language model. This separation also improves trust. A user can regenerate the interpretation for the same stored draw without receiving a completely different set of cards. The context builder turns raw product state into an object the model can reliably interpret. ``` { "question": "What should I consider before changing careers?", "spread": { "name": "Three Card", "positions": ["What shaped this", "Current reality", "What to explore next"] }, "cards": [ { "name": "Eight of Pentacles", "orientation": "upright", "position": "What shaped this", "coreMeaning": "Skill development, repetition, and craftsmanship" }, { "name": "Two of Swords", "orientation": "reversed", "position": "Current reality", "coreMeaning": "Avoided decisions, information overload, and internal conflict" }, { "name": "The Fool", "orientation": "upright", "position": "What to explore next", "coreMeaning": "A new beginning, openness, and a considered leap" } ] } ``` Structured input has several advantages over a long natural-language prompt. It is easier to inspect, log, validate, version, and reproduce. It also makes it clear which statements are application-provided facts and which statements are model-generated interpretation. The reader prompt should define behavior rather than merely say, "You are a tarot reader." Useful instructions include: The output should feel specific without becoming absolute. Compare these two statements: The Fool means you will leave your job and become successful. and: The Fool introduces the possibility of a new beginning, but beside the reversed Two of Swords it may be asking whether your desire for change is being clarified or simply used to escape a difficult decision. The second statement stays grounded in the supplied cards, connects their meanings, and gives the user something to examine. It does not present a generated sentence as a guaranteed event. The first interpretation should not be the end of the experience. Users often want to ask: A conversational interface allows the reading to become progressively more relevant. It also introduces new engineering requirements: conversation history, context limits, streaming responses, cancellation, retry behavior, moderation, and memory controls. The interface should preserve the original draw as stable context while clearly separating later discussion from the card facts. Streaming can reduce perceived latency, while suggested follow-up questions can help users continue without forcing them into an endless chat loop. One of the most interesting possibilities is offering multiple AI readers. One reader might be warm and emotionally attentive. Another might be concise and analytical. A third might focus on archetypes and storytelling. The same cards can support different lenses without changing the underlying facts. A useful reader persona should influence: Persona consistency is difficult. A name, avatar, and two adjectives in a system prompt are not enough. Each reader needs a small character specification with voice rules, reasoning priorities, examples, prohibited patterns, and test conversations. The persona should never override safety or factual grounding. A mysterious reader can still say, "This is one possible interpretation," and a direct reader should not turn uncertainty into false confidence. Connecting an application to an LLM API is straightforward. Producing readings that remain coherent, useful, and trustworthy is much harder. Models easily produce advice that could apply to anyone: trust yourself, embrace change, communicate openly. Those statements are not always wrong, but repeated often enough they make every reading feel interchangeable. The prompt should require references to the actual card relationships, spread positions, and user question. Evaluation should penalize sentences that would remain unchanged if the cards were swapped. If the model already knows something about tarot, it may combine its internal knowledge with the supplied dataset. That can introduce conflicting meanings or even the wrong card. The prompt should treat the provided reading context as authoritative. Server-side validation can ensure every card ID, orientation, and position is valid before the request is sent. For higher consistency, the model can return a structured draft before the final prose is rendered. A weak three-card reading is just three independent card descriptions. A strong reading explains how the cards modify one another. The model should be asked to identify progression, contrast, reinforcement, and unresolved tension. Spread positions matter here: The Fool in an "obstacle" position should not be interpreted exactly like The Fool in a "next step" position. Rich prompts, multiple personas, conversation history, and long outputs can become expensive quickly. Practical controls include: Performance is part of the experience. A beautiful card reveal loses its emotional effect if a large JavaScript bundle and an oversized prompt leave the user staring at a spinner. Tarot terminology is not always translated literally. Tone, sentence structure, card names, and the cultural weight of certain symbols vary by language. A multilingual reader needs more than translated buttons. Card data, reader voice, prompt examples, safety language, and output evaluation should all be reviewed per locale. The model should receive the requested locale explicitly instead of guessing from a short user question. There is no single correct paragraph for a tarot reading, but that does not mean quality is impossible to measure. I would evaluate generated readings across a rubric like this: | Dimension | Question | |---|---| | Card fidelity | Does the response use the supplied cards, orientations, and meanings accurately? | | Positional fidelity | Does each interpretation respect the card's role in the spread? | | Relevance | Does the reading address the user's actual question? | | Synthesis | Does it connect the cards rather than list them separately? | | Specificity | Could the response be reused unchanged for a different draw? | | Agency | Does it help the user reflect without dictating a decision? | | Uncertainty | Does it avoid presenting speculation as fact? | | Persona consistency | Does the reader maintain its intended voice? | | Safety | Does it handle high-stakes topics and emotional vulnerability responsibly? | A small library of representative questions and fixed card draws can become an evaluation suite. Each prompt or model change can be tested against the same cases. Human review remains important, but automated checks can catch invented cards, missing positions, prohibited certainty language, structural failures, and excessive repetition. This is one of the broader lessons from the project: subjective AI products still benefit from explicit quality criteria. Tarot questions can be deeply personal. People may discuss relationships, grief, health, money, loneliness, or major life decisions. That makes responsible design part of the core architecture, not a disclaimer added before launch. An AI tarot product should: It should also preserve user agency. The reader can offer a perspective, but the user should remain the person who decides what the perspective means and whether to act on it. The healthiest version of this product is not an oracle that demands trust. It is a reflective tool that invites thought. The current chat-based experience is only one possible form. With explicit permission, a reader could remember recurring themes, previous cards, and goals the user chose to track. It could notice that the same conflict has appeared across several readings or invite the user to compare how their interpretation has changed. The difficult part is not storage. It is deciding what deserves to be remembered, how to summarize it accurately, and how to make memory visible and controllable. A voice reader could make the experience feel closer to a guided reflection session. Real-time speech also raises the standard for latency, interruption handling, emotional tone, and safety responses. Computer vision could allow users to photograph a physical spread. The system could identify the cards and orientations, ask the user to confirm the result, and then use the same structured interpretation pipeline. Confirmation is essential. A visually similar card or an incorrectly detected reversal should not silently become part of the reading. Instead of asking one model to produce the definitive answer, a product could offer several lenses on the same draw: emotional, analytical, archetypal, or action-oriented. The value would come from comparison, not consensus. Future readers could show why a sentence appeared by linking it to a card, orientation, spread position, or prior user statement. This would make the boundary between data and interpretation more visible and help users challenge the reading rather than passively accept it. Professional tarot readers could use AI to organize notes, recall card relationships, translate a reading, or generate follow-up prompts while keeping the human reader responsible for the session. In that scenario, AI is not a replacement for human judgment but an interface for structured assistance. The long-term advantage of an AI tarot product will probably not come from choosing a particular model provider. Models improve, prices change, and APIs become interchangeable. The more durable work is elsewhere: In other words, the model is important, but it is only one layer of the product. Building an AI tarot reader has changed the way I think about both tarot and language models. Tarot provides a constrained symbolic vocabulary. The user provides a real situation. The application provides structure and trusted facts. The model connects those pieces into language. When those responsibilities are kept separate, the result can be more than a random card and more honest than an artificial prophecy. AI does not need to prove that tarot predicts the future. The more interesting question is whether symbols, stories, and conversation can help people see their present situation differently. That is the idea I have been exploring through [Random Tarot](https://randomtarot.org): not an AI that knows your destiny, but a reader designed to support context-aware reflection. I would love to hear how other developers would approach the hardest parts of this system. How would you evaluate subjective output? What should an AI reader remember? Where should the boundary between interpretation and advice be drawn? Those questions may be more valuable than any single card the system can reveal.