The switches in your agent workflow that nobody reads

Description and use

Many switches in agent workflow configurations are declared, validated, and documented but never actually read by any behavior‑changing code, leading to false confidence and wasted effort. A three‑step audit identifies and removes or wires up these dead switches, improving correctness and transparency.

Problem

Many configuration switches in agent workflows are declared, validated, and documented but never actually read by any behavior‑changing code, leading to false confidence and wasted effort.

Outcome

The audit revealed that most switches were only validated, not consumed. Only one knob actually changed behavior; others were either gated checks or inert. The process also uncovered a high proportion of duplicated reference cards in dispatched contexts, highlighting a separate cost issue.

Workflow

• List every config key from the schema or documentation.
• Grep the codebase for each key and classify hits as schema/enum, validator branch, metadata/pass‑through, or behavior branch.
• Adjudicate keys with zero behavior branches: wire them up or delete them.
• Document the decision and update the config accordingly.

Evidence

A switch can be declared, documented, schema-validated, and still have zero effect, because validation only proves the declaration is well-formed, never that anything acts on it.

Source

Step 2 — For each key, find its read points. Grep the codebase for the key name, then classify each hit: schema/enum definition, validator branch, metadata/pass‑through, behavior branch.

Source

We ran this audit on our own protocol, which has six knobs that look like they tune how much process a task goes through.

Source

46% of the bytes we shipped to our own agents were injected reference cards, and 38% of the total was the same card sent again.

Source