sir-thaddeus AGENTS.md

Sir Thaddeus Agent Guide

Scope

Apply this guide to the entire repository. Treat more-specific AGENTS.md files, when present, as additional instructions for their directory only.

Product objective

Sir Thaddeus is a local-first assistant intended to show that a small model can complete a large share of ordinary work when deterministic capabilities, memory, permissions, tools, and observable verification are used well.

Keep two claims separate:

• Model capacity: closed-book knowledge and reasoning, measured with MMLU and related controls.
• Harness capability: successful user outcomes created by tools, retrieval, state, permissions, and external verification.

Do not substitute one score for the other. State the primary metric before an experiment begins. Preserve raw-model language quality while improving product capability.

Track product quality as a third, independent scorecard: latency, safety, personality, continuity, validity, permissions, false success, and resource use. Changing to a larger or newer model may be a useful deployment comparison, but it is not evidence that the harness improved the fixed model under test.

Required orientation

Before changing assistant behavior, read:

1. docs/ASSISTANT_PIPELINE.md for the supported production path and retired experiments.
2. docs/EXPERIMENTATION.md for benchmark and promotion policy.
3. docs/TESTING.md for the narrowest trustworthy verification command.

For optimization work, also read docs/CALIBRATED_IMPROVEMENT_PLAN.md and the current evidence in docs/research/ before selecting a candidate.

Use THADDEUS_ROUTING_LATENCY_SCOPE.md as historical evidence, not as the current architecture contract. Verify drift-prone claims against current code, GitHub state, and fresh artifacts.

When available, use the sir-thaddeus-experiment-loop skill for MMLU, harness, prompt, routing, model-comparison, latency, VRAM, or benchmark work.

Production invariants

• Preserve safety boundaries, personality, memory, dialogue continuity, permissions, tool policy, auditing, sanitization, and explicit response contracts unless the task explicitly changes one of them.
• Keep desktop and headless behavior aligned.
• Keep benchmark datasets, expected answers, suite identifiers, scorer logic, and promotion thresholds outside production assemblies.
• Prefer a generalized fix at the narrowest product seam over a broad rewrite.
• Do not retain rejected behavior behind a disabled flag. Remove it.
• Treat external tools and model providers as untrusted boundaries.