Structure & Data

01. Structured Output Constrain the model's output to conform to a JSON Schema (or similar typed shape). Best for: Downstream code consumes typed data and free-form text would break parsers. Tradeoff: Provider lock-in for the strictest modes. Watch for: Output is for human consumption only and structure adds no value.

02. DSPy Signatures Specify agent behaviour as declarative typed signatures and modules; compile prompts and few-shot examples automatically against a metric. Best for: Hand-crafted prompts are brittle and drift across model versions. Tradeoff: Compilation requires labelled or auto-evaluable data. Watch for: The pipeline is a single prompt and the DSPy machinery is overkill.

03. Business + LLM Microservice Split Split an LLM application into a CPU-bound business microservice (retrieval, prompt assembly, orchestration) and a GPU-bound LLM microservice (only model.generate behind REST), so each tier scales on its own hardware budget. Best for: LLM inference and business logic have diverging scaling profiles. Tradeoff: One extra network hop per LLM call — latency cost. Watch for: Very low traffic — one service is simpler and within budget.

04. FTI LLM Pipeline Split Decompose an LLM/RAG system into three independently-deployable pipelines — feature, training, inference — communicating only via a feature store and a model registry. Best for: Feature, training, and inference have materially different cadences and ownership. Tradeoff: Two integration surfaces to operate and version. Watch for: System is small enough that one repository and one deploy cycle is fine.

05. Schema Extensibility Build schemas that evolve without breaking old clients via reserved namespaces and extension blocks. Best for: Schemas are long-lived and will accumulate fields over time. Tradeoff: Extension proliferation is a real risk. Watch for: The schema is internal, short-lived, and a single client owns it.