Why AI Shouldn't Orchestrate Workflows

I’ve learned through experience that there’s a fundamental truth about AI-assisted development: AI enforcement is not assured.

You can write the most detailed skill file. You can craft the perfect system prompt. You can set up MCP servers with every tool imaginable. But here’s the uncomfortable truth: the AI decides whether to follow any of it.

That’s not enforcement. That’s hope.

TL;DR: LLMs are probabilistic and can’t guarantee workflow compliance. Skills and MCP tools extend capabilities but don’t enforce behavior. Claude Code Hooks solve this by providing deterministic control points—SessionStart, PreToolUse, and PostToolUse—that ensure critical actions always happen. As AI-generated code scales, you need automated validation systems that codify architectural rules, business constraints, and design patterns. Workflow orchestration must live outside the AI.

The Fundamental Problem: LLMs Are Probabilistic, Not Deterministic

LLMs are probabilistic, not deterministic. When you tell Claude to “always read the skill file first” or “always call this MCP tool before responding,” you’re giving it a suggestion. A strong suggestion, maybe. But still a suggestion.

1
2
3
4
5
6
7

System Prompt: "ALWAYS read the skill file before proceeding"
         ↓
    AI interprets this instruction
         ↓
    AI *decides* whether to comply
         ↓
    No external mechanism verifies compliance

I’ve seen this play out repeatedly. The AI might:

• Think it already “knows” how to do something
• Interpret the task as not requiring the skill
• Shortcut due to context length pressure
• Simply… not follow the instruction 5% of the time

That 5% might seem small until you’re running autonomous agents in production.

Why Skills and MCP Aren’t Enough

Don’t get me wrong—skills and MCP servers are valuable. They extend what the AI can do. But they don’t control what it will do.

Consider this scenario:

1. You create a detailed skill file with your deployment workflow
2. You set up an MCP server with deployment tools
3. You tell the AI to “follow the deployment skill”
4. The AI decides it knows better and skips step 3

The skill existed. The MCP tool was available. The AI chose not to use them. Where’s your enforcement?

This isn’t a bug in the AI. It’s a fundamental architectural mismatch. You’re asking a probabilistic system to provide deterministic guarantees.

The Architectural Principle

Here’s the insight that changed my approach: workflow orchestration must live outside the AI.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

┌─────────────────────────────────────────────────┐
│         External Orchestration Layer            │
│  (Deterministic: State machines, workflow       │
│   engines, hooks, validation scripts)           │
└─────────────────────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────┐
│              AI as a Tool                       │
│  (Probabilistic: Understanding, generation,    │
│   judgment calls, handling variations)          │
└─────────────────────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────┐
│           Validation Layer                      │
│  (Deterministic: Schema validation, business   │
│   rules, output constraints)                    │
└─────────────────────────────────────────────────┘

The AI becomes a tool within the workflow, not the orchestrator of it.

This isn’t about distrusting AI. It’s about using each component for what it’s good at:

Claude Code Hooks: Deterministic Control for AI Workflows

This is where Claude Code’s Hooks system becomes genuinely exciting. Hooks provide what I’ve been describing: deterministic control over AI behavior.

Claude Code’s hooks system enables exactly this: hooks are user-defined shell commands that execute at specific points in Claude Code’s lifecycle. They provide deterministic control over Claude Code’s behavior, ensuring certain actions always happen rather than relying on the LLM to choose to run them.

That’s the key insight: ensuring certain actions always happen rather than relying on the LLM to choose.

Hook Types That Enable Enforcement

SessionStart — Inject context before the AI even begins:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "cat /path/to/required-skill.md"
          }
        ]
      }
    ]
  }
}

The skill content gets injected into context. The AI doesn’t decide to read it—it’s already there.

PreToolUse — Validate before any action executes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/validate-workflow-step.sh"
          }
        ]
      }
    ]
  }
}

Your validation script can check: “Has the required prerequisite been completed?” If not, exit with code 2 to block the action.

PostToolUse — Enforce standards after every change:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit:*.ts|Edit:*.tsx",
        "hooks": [
          {
            "type": "command",
            "command": "pnpm type:check --noEmit"
          }
        ]
      }
    ]
  }
}

Every TypeScript edit triggers type checking. The AI can’t skip it.

A Practical Enforcement Pattern

Here’s how I’d enforce a deployment workflow:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/load-deployment-context.sh"
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/check-deployment-prerequisites.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/verify-deployment-step.sh"
          }
        ]
      }
    ]
  }
}

The check-deployment-prerequisites.sh script might look like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

#!/bin/bash
# PreToolUse hooks receive tool information via stdin as JSON
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command')

# Check if this is a deployment command
if echo "$COMMAND" | grep -qE "deploy|push|release"; then
  # Verify tests have passed
  if [ ! -f ".deployment-tests-passed" ]; then
    echo "Blocked: Tests must pass before deployment" >&2
    exit 2  # Block the action
  fi

  # Verify staging was validated
  if [ ! -f ".staging-validated" ]; then
    echo "Blocked: Staging must be validated before production" >&2
    exit 2
  fi
fi

exit 0  # Allow the action

Now the AI cannot deploy without completing prerequisites. It’s not a suggestion. It’s enforcement.

The Remaining Gap

Hooks get us most of the way there, but there’s still no native “require this tool call before responding” mechanism. You can’t say “Claude must call the linting MCP tool before any code generation.”

However, you can approximate it:

• SessionStart injects requirements into context
• PreToolUse blocks actions that violate workflow order
• Validation scripts track state and enforce prerequisites
• Exit code 2 provides feedback to Claude about why actions were blocked

Building Automated Validation Systems for AI-Generated Code

Here’s where things get interesting: as the speed of AI code generation or output accelerates, manual review becomes a bottleneck. You need automated validation that understands your architecture.

This isn’t about linting or formatting. Those are syntax-level checks. I’m talking about validating:

• Architecture compliance: Does this new service follow our microservices patterns?
• Dependency constraints: Is this package allowed to import from that layer?
• Design pattern adherence: Are we using the repository pattern correctly?
• Library usage rules: Are we using the approved authentication library, not rolling our own?

The value isn’t in having AI remember these rules (it won’t consistently). The value is in codifying the rules so validation is automated.

A note on spec-driven development: You might think, “I’ll use spec-first approaches and let AI generate everything from specifications.” But specs don’t solve the maintainability problem. You’re still supporting AI-generated code at the end. If that code is unmaintainable—overly complex, poorly structured, or violating your architectural patterns—you’ll be in a world of pain when bugs appear or requirements change. Validation must check not just correctness against specs, but also code quality, maintainability, and adherence to your team’s patterns.

The Meta-Pattern: AI Building Validation for AI

Here’s the evolution I’ve observed:

Phase 1: You write validation scripts manually

1
2
3
4
5
6

#!/bin/bash
# Check if new files violate package structure
if ls src/ui/components/**/data-access-*.ts 2>/dev/null; then
  echo "Error: UI components cannot directly access data layer"
  exit 1
fi

Phase 2: You use AI to help write validation scripts

1
2
3

# You tell Claude: "Write a script that ensures our
# feature modules don't import from each other"
# Claude generates the validation logic

Phase 3: AI maintains validation as architecture evolves

1
2
3

# Your SessionStart hook loads architectural rules
# AI suggests: "I notice you're adding a new module type.
# Should I update the validation script to include it?"

This is the meta-pattern: AI helps build and maintain the validation systems that validate AI-generated code.

Codifying Architectural Rules

The key is making your architectural constraints executable. Here’s a practical example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#!/bin/bash
# validate-package-architecture.sh
# Enforces: Feature packages can only depend on shared packages

CHANGED_FILES=$(git diff --name-only HEAD)

for file in $CHANGED_FILES; do
  if [[ $file =~ ^packages/features/([^/]+)/ ]]; then
    FEATURE=${BASH_REMATCH[1]}

    # Check imports in this file
    IMPORTS=$(grep -E "from ['\"]@/" "$file" || true)

    # Block imports from other features
    if echo "$IMPORTS" | grep -E "@/features/(?!$FEATURE)" &>/dev/null; then
      echo "❌ Architecture violation in $file"
      echo "Feature packages cannot import from other features"
      echo "Allowed: @/shared/*, @/features/$FEATURE/*"
      exit 2  # Block the action
    fi
  fi
done

echo "✅ Package architecture valid"
exit 0

Hook this into PostToolUse for Edit operations:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit:packages/**/*.ts",
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/validate-package-architecture.sh"
          }
        ]
      }
    ]
  }
}

Now the AI cannot violate your package architecture. It will get immediate feedback: “This import violates the feature isolation rule.”

Validation That Evolves With AI Adoption

As AI generates more code, your validation needs shift:

Early AI adoption:

• Focus: Syntax, types, tests
• Tools: Linters, type checkers, test runners
• Scope: Individual files

Scaling AI usage:

• Focus: Architecture, patterns, cross-cutting concerns
• Tools: Custom validation scripts, dependency analyzers
• Scope: Module boundaries, system integration

AI-pervasive development:

• Focus: Business rules, domain invariants, compliance
• Tools: AI-assisted validation, semantic analysis
• Scope: Business logic correctness, regulatory compliance

The pattern: validation moves up the abstraction ladder as AI handles lower-level concerns more reliably.

Practical Validation Beyond Syntax

Here are validation scripts I’ve found valuable:

Database migration safety:

1
2
3
4

# Ensure migrations are reversible and safe
if git diff --name-only HEAD | grep -q "migrations/"; then
  ./scripts/analyze-migration-safety.sh || exit 2
fi

API contract enforcement:

1
2
3
4

# Ensure API changes don't break existing contracts
if git diff --name-only HEAD | grep -q "src/api/"; then
  npm run api:validate-contracts || exit 2
fi

Security boundary validation:

1
2
3
4

# Ensure authentication is required on new routes
if git diff HEAD | grep -E "^\+.*@(Get|Post|Put|Delete)"; then
  ./scripts/check-auth-decorators.sh || exit 2
fi

Each script encodes knowledge about your system. The AI doesn’t need to remember these rules—it gets immediate feedback when it violates them.

The Investment Pays Off at Scale

Building validation systems feels like overhead initially. But consider:

• Without validation: You review every AI-generated change manually
• With validation: AI gets instant feedback, you review only what passed automated checks

As AI velocity increases, the ROI of automated validation becomes asymptotic. You’re essentially building a continuous code review system that operates at machine speed.

The humans-and-AI partnership becomes:

1. Humans: Define architectural rules and business invariants
2. AI: Generates code and helps build/maintain validation systems
3. Validation systems: Ensure AI-generated code complies with human-defined rules
4. Feedback loop: Violations inform both AI (immediate) and humans (for rule refinement)

When to Use Each Approach

Frequently Asked Questions

Q: Can’t I just write better prompts to ensure AI follows instructions? A: No. LLMs are probabilistic systems. Even the best prompts are suggestions, not guarantees. You need external enforcement mechanisms like hooks to ensure critical workflows execute correctly every time.

Q: What’s the difference between skills and hooks in Claude Code? A: Skills tell Claude what to do and how to do it—they’re like documentation and guidelines. Hooks ensure it happens by providing deterministic control points in the workflow. Skills extend capabilities; hooks provide enforcement.

Q: Do I need hooks for every AI interaction? A: No. Use hooks for critical workflows (deployments, financial transactions, security validation) and quality enforcement (linting, type checking). For advisory tasks, brainstorming, or exploration, skills and prompts are sufficient.

Q: Can hooks completely replace human oversight? A: Hooks provide automated enforcement of known rules and workflows, but human judgment is still essential for architectural decisions, edge cases, and situations requiring contextual understanding.

Q: Should I build custom validation scripts or just rely on standard tools like linters? A: Both. Linters handle syntax and style, but as AI generates more code, you need custom validation for architecture compliance, business rules, and domain-specific constraints. Start with one critical architectural rule (like package isolation or API contract validation), codify it as a script, and expand from there. The investment pays off exponentially as AI velocity increases.

The Shift Left Evolution: From DevOps to AI-Augmented Development

Remember when tech adopted Infrastructure as Code? We shifted validation left—catching issues earlier in the development cycle through automation and testing.

With AI-augmented development, we’re teleporting even further left. We now need automation validation—not just for deployments and releases, but for the AI-generated code itself and the workflows that produce it.

The same shift-left principles apply:

• Deployments: Validate before production (we learned this in DevOps)
• Releases: Validate before deployment (we learned this in CI/CD)
• Code Generation: Validate immediately after the AI writes it (we’re learning this now)

The difference? AI assistance makes implementing these validations simpler. Hooks, skills, and MCP tools give you the building blocks. The architecture just needs to be right: validation lives outside the AI.

The Bottom Line

If you need guarantees that AI follows a workflow, the workflow logic must live outside the AI. Full stop.

Skills and MCP extend capabilities. Hooks provide enforcement. Use them together:

1. Skills define what to do and how
2. MCP servers provide the tools to do it
3. Hooks ensure it actually happens

Start Small

Don’t try to hook everything at once. Start where it matters most:

1. Identify your ONE most critical workflow (likely: deployments or production releases)
2. Add a single PreToolUse hook to validate prerequisites (tests passed, staging validated)
3. Codify ONE architectural rule as a validation script (e.g., package isolation, API contracts)
4. Observe the impact for a week—you’ll catch violations you didn’t know were happening
5. Expand incrementally to other critical paths (security, data operations, business rules)
6. Remember: Don’t hook everything—only what needs guarantees

Stop hoping your AI will follow instructions. Build systems that make compliance deterministic.

About this post: This article was written by Claude (Anthropic’s AI assistant) with guidance and direction from Eric Gulatee. The insights and architectural patterns reflect real-world experiences in building AI-augmented development workflows.

This post is part of a series on building reliable AI-augmented development workflows. See also: LLM Output Requires Validation for validation feedback loops that complement the architectural patterns discussed here.