Independence From AI

Independence from AI

Audit workflows for unnecessary dependence on free-form LLM reasoning.

The goal of this skill is not to remove the model from the system. The goal is to move the repeatable, critical, threshold-based, and deterministic parts of a workflow out of prompts and into architecture.

Core principle

Use the lowest reasonable layer for each kind of logic.

If a process is repeated, critical, or threshold-based, it probably lives too high in the stack.

Responsibility stack

Evaluate workflows using this stack, from strongest to weakest for deterministic control:

1. State -- source of truth, status, ownership, thresholds, cooldowns, locks, categories
2. Triggers / event hooks -- what starts the action
3. Scripts / tools / automations -- deterministic execution
4. Skills / runbooks / procedures -- reusable workflows and decision trees
5. Policy / documentation -- constraints, standards, architecture rules
6. LLM reasoning -- synthesis, ambiguity handling, trade-offs, summaries, explanations

What should stay in the LLM

Keep these primarily in the model:

• synthesis across multiple signals
• ambiguous interpretation
• architecture trade-offs
• human-facing explanations
• improvement proposals
• flexible summaries for humans

What should not stay in the LLM by default

Do not keep these primarily in the model when they can be systematized:

• thresholds
• deduplication
• cooldown logic
• severity mapping
• deterministic routing
• critical alert gating
• ownership rules
• state transitions
• retry policy
• repeated output formatting
• classification that should be stable over time

Key invariants

1. Documents are not runtime. If a rule exists only in docs, it does not reliably exist in the system.
2. Text is not state. If a status or decision matters operationally, it should exist in structured state.
3. Critical signal quality should not depend on free-form reasoning alone.
4. Repeated logic should not be reinvented every run.
5. Housekeeping, alerting, and summarization are different layers and should not be mixed carelessly.

Anti-patterns

1. Prompt-as-system

The workflow works only because the prompt reminds the model what to do every time.

2. Docs-as-runtime

A rule is written down, but nothing in the system enforces or executes it.

3. Reasoning-in-the-critical-path

A critical alert or decision depends on how the model happens to interpret the situation that day.

4. Text-replaces-state

Important operational facts live only inside messages, summaries, or prose.

5. Repeated-formatting-by-reasoning

The model reconstructs the same structure, report, or decision format over and over.

6. Mixed layers

Housekeeping, internal logging, escalation, and user-facing summaries are merged into one output.

7. Duplicate coordination logic

The same routing, ownership, or summary logic exists in multiple places and drifts over time.

Audit questions

For any workflow, ask:

1. Where does the source of truth live?
2. What logic is repeated with little or no variation?
3. What decisions should be deterministic but currently live in reasoning?
4. Which part should exist as structured state?
5. Which part should be a trigger, hook, or automation?
6. Which part should be procedural knowledge in a skill or runbook?
7. If the model forgot the rule, would the workflow break?
8. Are housekeeping and user-facing signal separated clearly?
9. Are there duplicated rules across prompts, docs, and system behavior?
10. After moving mechanics downward, what valuable work still remains for the model?

Refactor rules

Move to state when:

• it represents status, owner, threshold, cooldown, severity, category, or lock
• multiple actors need to read it consistently
• downstream decisions depend on it

Move to triggers / hooks when:

• an action should happen automatically after a known event
• timing or initiation should not depend on the model remembering to do it

Move to scripts / tools / automations when:

• the operation repeats frequently
• the operation is fragile or error-prone
• deterministic output matters
• the same formatting or transformation is rebuilt repeatedly

Move to skills / runbooks when:

• the workflow is reusable but still requires contextual judgment
• a stable procedure or decision tree exists
• an operator or agent needs reusable operational guidance

Leave in the LLM when:

• the situation is ambiguous
• synthesis matters more than determinism
• trade-offs need interpretation
• the output is primarily for human understanding

Common workflow targets

This skill is especially useful when auditing:

• triage flows
• task routing
• escalation boundaries
• summaries and reports
• alerting pipelines
• coordination workflows
• content or operations pipelines
• anti-duplication in multi-agent systems

Output format

For each finding, produce:

Process | Current layer | Problem | Target layer | Action

Example:

Task routing | LLM reasoning | assignment logic is repeated manually and drifts | Skill + state | move routing matrix into procedure and store task category in structured state

Guardrails

• Do not use this skill as an excuse for unnecessary rewrites.
• Do not replace working systems just to make them look “more architectural”.
• Do not confuse documentation with enforcement.
• Do not collapse operational state into prose.
• Do not keep critical signal quality dependent on free-form reasoning when a lower layer would do better.
• Prefer minimal, targeted moves down the stack over broad abstract redesigns.

Definition of done

This skill has been applied well when:

• a concrete area of unnecessary LLM dependence is identified
• a lower target layer is chosen intentionally
• a specific action is proposed
• state, execution, procedure, policy, and reasoning are clearly separated
• noise is reduced and signal becomes more reliable
• it is clear what the model no longer needs to “keep in its head”