agent-tech-chooser

Agent Tech Chooser

Use this BEFORE writing the first line of agent code. The goal is to stop you from reaching for LangGraph out of habit where client.messages.create(...) in a loop is enough — and the reverse: to stop you from hand-rolling fragile orchestration where you actually need a graph with checkpointing.

When to use

• The user states an agent/LLM-feature task and the stack is not yet fixed.
• You hit murky architecture in existing code ("2 LLM calls + a manual if/else + a state variable") and can't tell whether to refactor into LangGraph or simplify down to a single call.
• A task arrives to integrate a new tool/provider and you need to know whether it breaks the current stack.

When not to use

• The stack is already chosen and fixed in the project (CLAUDE.md / architecture doc). Just follow it.
• The task is not an agent at all — it's classic ETL/CRUD/rules. No LLM needed.
• Pure prompt-tuning inside an already-working agent.

Algorithm

1. Ask (or extract from context) the 6 trigger questions from RUBRIC.md. Don't skip any — each one rules out one or two options.
2. Run the answers through the decision tree (RUBRIC.md, "Decision tree" section). Most tasks are decided in the first 2-3 questions.
3. Cross-check against RAG — only if the search_agent_knowledge tool is available in the current session (optional — this assumes a local knowledge-retrieval MCP tool; without it, skip this step, the rubric is sufficient): search_agent_knowledge("<chosen stack> when to use") — if there's a distilled card on the stack's boundaries of applicability, confirm the task falls inside them.
4. Deliver the verdict in this format:
   • Recommendation: <stack> — one line.
   • Why: 1-3 bullets grounded in the answers from step 1.
   • Alternative: <second_stack> — when to pick it instead.
   • Red flags: a list of "if X shows up in the task — revisit the choice."

Principles (more important than the tree)