DSPy

In this catalog it is the Frameworks option when you need to compose multi-step agent loops and tool handoffs. Keep DSPy on the observe/propose side of the loop: useful signals and drafts, with human or policy authority still required before anything irreversible runs.

DSPy programs LM pipelines as modules with signatures, then optimizes prompts/weights against metrics (teleprompters) instead of hand-tuning strings.

1. Declare signatures and modules (Predict, ChainOfThought, …).
2. Compose a program over datasets.
3. Optimize with a teleprompter against a metric.
4. Compile/run the optimized program in production.

Related: mirascope · topics/32-eval-harnesses · topics/12-central-nervous-system

• Use when: DSPy (Stanford) is a declarative framework for programming language-model pipelines as composable modules with signatures, and for optimizing those pipelines with teleprompters against metrics matches the bottleneck and you specifically need to compose multi-step agent loops and tool handoffs.
• Skip when: another pack already covers the need with less ops surface, or DSPy would become a second place people retype truth.
• Prefer instead: compare Mirascope before locking the cell.

• Ops: confirm license, hosting, and release cadence for DSPy (stanfordnlp/dspy) before relying on it in a live corridor.
• Integration: bad credentials, scopes, or schema drift produce empty retrievals or runaway tool/model spend without an obvious UI alarm.
• Scope: Frameworks components support agents; they are not the company ledger or the approval authority.