Design LLM Project Architectures and Pipelines

This skill provides a methodology for identifying tasks suited to LLM processing, designing effective project architectures, and iterating rapidly using agent-assisted development - applicable whether building a batch processing pipeline, a multi-agent research system, or an interactive agent application. It covers task-model fit recognition (LLM-suited tasks: synthesis across sources, subjective judgment with rubrics, natural language output, error tolerance, batch processing, in-training domain knowledge; LLM-unsuited tasks: precise computation, real-time requirements, perfect accuracy needs, proprietary data dependence, sequential dependencies, deterministic output requirements), validated through a manual prototype step before any automation is built. It defines a canonical five-stage pipeline architecture (acquire, prepare, process, parse, render) where only the process stage is non-deterministic and expensive, uses the file system as a state machine (one directory per item, stage completion marked by file existence, enabling idempotency, debugging, and parallelization), and covers structured output design (section markers, format examples, disclosing that parsing is programmatic, robust parsers that handle format variation gracefully). It also covers agent-assisted development iteration, cost/scale estimation formulas, single- vs multi-agent architecture selection (multi-agent for context isolation, not role-play), and architectural reduction (removing specialized tools when they constrain more than they enable, citing Vercel's d0 agent going from 17 tools/80% success to 2 tools/100% success).

Use it when starting a new project that might benefit from LLM processing, evaluating whether a task is well-suited for agents versus traditional code, designing the architecture for an LLM-powered application, planning a batch processing pipeline with structured outputs, choosing between single-agent and multi-agent approaches, or estimating costs and timelines for LLM-heavy projects.

The methodology's own anti-patterns are explicit warnings: don't skip manual validation before building automation (this wastes significant time when the approach is fundamentally flawed), don't build monolithic pipelines that combine all stages into one script (this makes debugging and iteration difficult), don't over-constrain the model with guardrails the model could handle on its own, don't ignore costs until production (token costs compound quickly at scale), don't expect LLMs to follow format instructions perfectly (build robust parsers instead), and don't add caching/parallelization/optimization before the basic pipeline works correctly. Treat its guidance as a methodology to apply with judgment to your specific project, not a substitute for testing your own task-model fit.

Input: a project idea or task that might involve LLM processing. Output: a task-model fit evaluation, a staged pipeline architecture, and a cost/scale estimate.

Canonical pipeline: acquire → prepare → process → parse → render
data/{id}/
├── raw.json         # acquire stage complete
├── prompt.md        # prepare stage complete
├── response.md      # process stage complete
├── parsed.json      # parse stage complete

Cost formula: Total cost = (items × tokens_per_item × price_per_token) + API overhead

Connects to companion skills context-fundamentals (prompt context constraints), tool-design (agent tool architecture and reduction patterns), multi-agent-patterns (single vs multi-agent architecture choice), evaluation (output/agent performance evaluation), and context-compression. References real case studies: Karpathy's HN Time Capsule (930-item batch pipeline, $58 total cost, ~1 hour execution) and Vercel's d0 text-to-SQL agent (17 tools to 2, 80% to 100% success rate).

Engineers and technical leads designing new LLM-powered projects or pipelines who want a validated, staged methodology for evaluating task fit, structuring pipelines, and estimating cost before committing to an architecture.