Choose AI-Native Stack
AI-native is a stack family only when AI tool/data/workflow integration is the product architecture. A chat box in an app is not enough.
AI-Native Wins When
- Users connect local files, databases, browsers, tools, or services to an AI assistant.
- MCP servers or similar connectors are part of the product surface.
- Tool execution needs permissions, inspection, sandboxing, or audit logs.
- Workspaces isolate prompts, documents, tools, models, and state.
- Local model runtimes or OpenAI-compatible local APIs are core.
- Context recovery and raw artifact preservation matter.
Minimum Starter Shape
| Layer | Minimum decision |
|---|---|
| UI | Desktop/web shell or CLI for control and review |
| State | SQLite or local durable store for sessions, memory, audit events |
| Tools | MCP or explicit tool adapter boundary |
| Security | Sandbox or restricted subprocess policy for risky tools |
| Workspace | Per-project data/tool/model isolation |
| Audit | Structured events, not scraped logs |
| Recovery | Raw outputs and artifacts preserved outside context windows |
Avoid AI-Native When
- A normal app with one AI API call solves the problem.
- Tool execution is unsandboxed but touches user files.
- The app requires PostgreSQL, Redis, containers, and multiple services before the v1 user value exists.
- You cannot explain connector scope and secret handling.
Warning: Prompts are not a security boundary. If AI can execute tools, the stack needs technical enforcement: permissions, sandboxing, logging, and reviewable scopes.