LLM App Patterns

🤖 LLM Application Patterns

Architecture and integration sketches for LLM applications, with explicit retrieval, tool, privacy and verification boundaries.

Detailed Guide

Read the detailed guide before executing this skill. It retains the complete procedure and reference material. Treat its safety, prerequisites, and validation requirements as mandatory. For focused work, load the relevant sections; for end-to-end work, read the guide completely.

When to Use This Skill

Use this skill when:

• Designing LLM-powered applications
• Implementing RAG (Retrieval-Augmented Generation)
• Building AI agents with tools
• Setting up LLMOps monitoring
• Choosing between agent architectures

Inputs, worked example and verification

Record provider/SDK versions, authorized data and tools, request/response schemas, latency/cost budgets and the expected task outcome. All code above is an integration sketch: llm, database, parser and provider-response adapters are project-owned and must be implemented explicitly. Never execute model-provided Python, expressions or fuzzy tool names; dispatch only exact registered tools after schema and authorization checks. Enforce per-call deadlines as well as loop limits.

Example: a planner first queues steps A and B, then after A replaces the remaining work with C. The executor must run A then C, never stale B. A parser step must apply the parser to the actual prior output. Two tenants with the same prompt must produce different cache keys, and cache reads/writes require an explicit reuse policy. These are concrete regression assertions; successful mocks still do not prove live provider behavior.

The limiter sketch is single-threaded and process-local. A distributed deployment needs a shared atomic limit and deadlines. Retry only retry-safe operations, honoring provider retry guidance; a timeout after a side effect is not evidence that nothing happened. See Tenacity retry predicates.

Limitations

• A retrieved source list does not prove each answer claim is supported; verify claim-to-source evidence and abstention behavior.
• Prompt text and JSON-shaped output are not authorization boundaries. Enforce permissions in the application.
• Provider failover can change output quality, tool schemas, cost and data residency; only use pre-approved compatible fallbacks.
• Caching must respect tenant access, data/prompt revisions and deletion policy; temperature zero does not make output deterministic.
• Model/SDK examples are not a complete service, benchmark or production-readiness certificate.