temper

MANDATORY PREPARATION

Over-Engineering Detection

• Multi-agent for a single-agent problem
• Premature optimization before you have performance data
• Abstraction layers with one implementation
• Configuration for things that never change
• Evaluation loops on non-critical outputs
• Framework before features

The Complexity Test

1. Is this solving a problem we actually have? (not "might have")
2. Is this the simplest solution that works?
3. Would removing this break anything? (if not, remove it)
4. Can someone new understand this in 5 minutes? (if not, simplify)

Tempering Strategies

OVER-ENGINEERED: User → Classifier → Router → Specialist → Formatter → Checker (6 components)
TEMPERED: User → Single Agent with good prompt (1 component, same quality)

OVER-ENGINEERED: class AgentOrchestrator with 5 strategy interfaces
TEMPERED: async function runWorkflow(input) — direct, readable

OVER-ENGINEERED: config.yaml (200 lines, 47 params, 3 inheritance levels)
TEMPERED: config.yaml (20 lines, essential params only, sensible defaults)

What NOT to Temper

• Error handling — essential, not overhead
• Logging — saves you when things go wrong
• Input validation — prevents cascading failures
• Core guardrails — safety is non-negotiable
• The golden test set — how you know it still works

Recommended Next Step

{{command_prefix}}evaluate

{{command_prefix}}diagnose

• Temper without measuring output quality before and after
• Remove error handling in the name of simplicity
• Simplify below the level of correctness
• Remove features users actively rely on