Sefism GenAI App Architecture Cheat Sheet

What this cheat sheet is

The Sefism GenAI app architecture cheat sheet is a quick-revision book on how the pieces of a real generative AI application connect. It follows one request from the chat box to the model and back, says which layer owns each step, and shows where retrieval, tools, memory, caching, guards, evals and tracing sit. It ends with a project layout you can copy and a checklist for launch.

It is a standalone sheet: it does not belong to one roadmap and has no editions, so every reader sees the same ten chapters and 58 concepts. Each concept is a short card with what it is, why it matters and, for many, the mistake people make with it. It is about the shape of the application, not which model or vendor to buy: for that, the sheet points you to the Choosing an LLM and AI stack roadmap.

Who it suits

• Developers who have called an LLM API and now need to turn a demo into an app with users, permissions, costs and logs.
• Students building a final year project on top of a model, who want each part of the code to have a clear home.
• Backend and full-stack engineers joining a team that already ships AI features, who want the vocabulary in one place.

If you are new to building with models, start with the AI engineering roadmap, which teaches prompting, RAG, agents and evals in order, and use this sheet to see how those parts fit together. The AI engineering cheat sheet goes deeper on retrieval, and the AI evals cheat sheet on the evaluation chapter.

Chapter by chapter

1. The request flow

What happens between a user pressing Send and the answer appearing: the request flow end to end, the AI orchestrator that decides what runs, a single model client wrapper, the data stores a GenAI app needs, and what belongs on the request path versus in background jobs.

2. Frontend and backend layers

What the browser owns (chat UI, streaming, file uploads, sign-in and history) and what the server owns before any model is called: authentication and authorisation, request validation, business logic kept outside the prompt, rate limits and quotas, and structured logging. The rule the chapter repeats: no model keys in the frontend.

3. The RAG pipeline

Where retrieval sits and who runs it: the ingestion job, the retriever, hybrid search and reranking, permission filters applied at retrieval time, and re-indexing and deletes. The techniques themselves are left to dedicated material; this chapter is about the moving parts.

4. Tools and the agent loop

How the orchestrator lets a model act: plan, act and evaluate, a tool registry, a fixed workflow before an agent, step, time and cost limits, approval for write actions, and MCP servers as a source of tools.

5. Memory, caching, rewriting and routing

The parts that make a chat feel continuous, cheap and fast: short-term and long-term memory, a semantic cache, prompt caching, query rewriting and model routing.

6. Three guard layers

Checks in three places: an input guard on what the user sends, a content guard on what the model reads (retrieved text and tool results), and an output guard on what it returns. Plus least privilege for tools and the cost of false positives.

7. The evaluation folder

Evals live in the repository next to the prompts they test: a golden set, offline evals, online evals and a tracked eval history.

8. Observability

Per-stage tracing of one request, capturing user feedback, a cost breakdown, and redaction and retention for logs that contain user text.

9. A reference project layout

One way to lay out the repository so each layer has a home: the folder layout, prompts as files, config and secrets, and agent instruction files such as AGENTS.md, CLAUDE.md and a rules folder. Rename freely; the point is that prompts, evals and agent instructions are files in Git.

10. Production checklist

What must be true before real users arrive: containers, CI/CD, secrets management, API security basics, monitoring and alerts, cost limits, and fallbacks with graceful failure.

Rules of thumb

The sheet ends with eight rules, including:

• Keep the orchestrator out of route handlers so evals can call it directly.
• Send every model call through one wrapper that logs model, tokens, cost and latency.
• Enforce permissions in the API and the retriever, never only in the prompt.
• Treat retrieved text and tool results as untrusted data, not instructions.
• Start with a fixed workflow and add an agent loop only for open-ended tasks.
• Set cost caps in your code and in the provider console before launch.

How to use it

• Before writing code, read chapters 1, 2 and 9, so every part of the app has a home from day one.
• When adding retrieval or tools, keep chapters 3, 4 and 6 open: most security bugs in AI apps come from skipping the permission filter or the content guard.
• Before launch, work through chapters 7, 8 and 10 as a checklist.

How it works on Sefism

Everything on Sefism is free to learn from. The public page lists all ten chapters, with the first chapters open to read. Keeping the sheet in your member area uses credits, like any cheat sheet; because it is standalone, it is not included with a roadmap. New members get starting credits when they join. If you are stuck on how to structure your own app, send Tauseef a query.

Related on Sefism

• Roadmaps: AI engineering, AI agents and MCP, Choosing an LLM and AI stack and AI security
• Cheat sheets: AI evals, LLM APIs and MCP
• FYP ideas: LLM gateway with semantic cache and model routing and Retrieval assistant for university regulations
• Resources: Building effective agents, Applied LLMs: what we learned from a year of building, Vercel AI SDK documentation, OWASP Top 10 for LLM Applications and Langfuse documentation

FAQ

What is an AI orchestrator? The part of your backend that decides what happens for one request: which context to fetch, which tools to offer, which model to call and what to check before answering. Keeping it separate from route handlers lets evals and background jobs call it directly.

Where should permissions be enforced in a RAG app? In the API and in the retriever, as a filter on which documents a user may see. A prompt that says "only use documents this user may see" is not a permission check.

Do I need an agent? Often not. The sheet's advice is to start with a fixed workflow and add an agent loop only for open-ended tasks, with step, time and cost limits and approval for write actions.

Which model or vendor should I use? This sheet does not choose for you. Follow the Choosing an LLM and AI stack roadmap for that decision.