# Independence From AI > Audit and redesign workflows that depend too much on LLM reasoning. Use when: (1) repeated operational logic still lives in prompts or model memory, (2) you are designing triage, routing, escalation, summaries, alerts, coordination, reporting, or content/ops pipelines, (3) you need to decide what should move out of the model and into system state, triggers, scripts, tools, runbooks, or policy, (4) a user asks to make an agent workflow more systematic, deterministic, less noisy, less fragile, or less dependent on “keeping things in the model’s head”, (5) you are auditing repeated workflows for drift, stale thresholds, duplication, inconsistent routing, or unstable alert quality. - Skill: `qwwiwi/independence-from-ai` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add qwwiwi/independence-from-ai` - Raw SKILL.md: https://api.skillmd.com/api/skills/qwwiwi/independence-from-ai/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: qwwiwi (https://skillmd.com/u/qwwiwi) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/qwwiwi/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”