AI Feature Patterns

September 5, 2026 ยท View on GitHub

Last verified: 2026-05

Use this when: the MVP might include product AI, RAG, tool calls, memory, voice, browser use, or local models.

Quick Answer

Default to the smallest useful AI feature:

  • Server-side model call
  • Structured output
  • Clear data boundary
  • Small eval set
  • Logging/cost limits
  • Human approval for risky actions

Choose A Pattern

NeedStart withAvoid at MVP
Generate text, classify, extract dataServer route + structured output schemaFree-form JSON parsing
Answer from project/private docsRAG with scoped retrieval and citationsDumping every file into context
Review a small stable corpusLong context plus caching where supportedPremature vector DB setup
Take user actionsTool calls with read/write/destructive classesAutonomous writes
VoiceRealtime only if speech is core UXVoice as decoration
Browser/computer useSandbox-only last-mile automationReplacing real APIs with clicks
MemoryExplicit user/project/session memory"Remember everything"
Local/private AISmoke-test output and tool calling firstAssuming local models behave like cloud models

Checklist

  • What can the model see?
  • What structured output does the app require?
  • What tools/actions can AI call?
  • Which actions need approval?
  • What happens when the provider fails or quota runs out?
  • What prompt set proves the feature works?
  • Where are traces, logs, and costs recorded?

Example

For an AI support assistant, start with read-only RAG over help docs, cite sources, block account changes, log trace IDs, and test direct, indirect, negative, auth-required, and failure prompts.

Worked outcomes and protocol evidence

For small existing-app, internal-automation, assistant-interface, and creative-code outcomes, use the worked recipes. They keep integration questions behind the relevant project route. Record actual client/SDK/protocol combinations using the compatibility evidence policy; a documented extension is not proof that the user's client implements it.