AI Agent Stack Builder

Assembles a recommended technology stack for AI agent projects based on declared use case, language preference, deployment target, and budget constraints. Output groups components by layer: LLM provider, orchestration framework, vector store, observability, and deployment runtime.

Recommendations follow current industry conventions and account for trade-offs between managed services and self-hosted infrastructure. Each suggestion includes a one-line rationale and notes on common failure modes encountered in production deployments.

The selection logic begins with hard constraints. Compliance flags (data residency, no third-party model calls) eliminate hosted-only providers immediately. Language preference narrows orchestration choices: Python opens LangChain, LlamaIndex, AutoGen, CrewAI; TypeScript narrows to LangChain.js, Vercel AI SDK, Mastra; Go and Rust have far fewer mature options. Once hard constraints filter the candidate set, the budget tier selects between managed and self-hosted alternatives within each surviving layer.

A worked example for "Python-based RAG over internal docs, AWS deployment, $200/month budget": the recommendation is OpenAI gpt-4o-mini for the model (low cost, strong instruction following), LlamaIndex for retrieval orchestration (better document loaders than LangChain for the typical PDF-and-Confluence corpus), pgvector on RDS for the vector store (avoids a second managed service), Langfuse self-hosted on a small EC2 instance for observability, and AWS Lambda for the runtime. Total monthly bill estimates at $80–150 with token usage dominating. Trade-offs noted: pgvector is slower than dedicated stores like Pinecone above ~5M vectors, but the corpus described won't reach that scale.

Common failure modes the recommendations encode: vector stores chosen before knowing chunk size and corpus growth (typically over-provisioned); observability deferred until a production incident (always too late); orchestration framework chosen for feature breadth rather than the team's actual graph complexity (a single-shot RAG flow does not need LangGraph). The defaults steer away from these. The recommendations are not optimal — optimality is workload-specific — but they avoid the most common avoidable mistakes.

Limitations: the recommendation is opinionated rather than personalized. A team with deep Kubernetes expertise gets the same Lambda suggestion as a team with no infrastructure background, despite a self-hosted Kubernetes deployment being objectively better-fitted to the former. The output is a starting point, not a substitute for an architect's judgment on context the form cannot capture.