AI Agents and the 'Code Exorcist' Pattern: How LLMs Are Redefining Debugging and DevOps Workflows in 2026

Originally published on tamiz.pro.

The most frustrating part of software engineering isn't writing code — it's finding out why the code broke. For decades, debugging has been a human-dominated craft: a developer stares at logs, reproduces a stack trace locally, sprinkles console.log calls, and slowly narrows a search space. In 2026, a new architectural pattern is quietly dismantling that workflow. The 'Code Exorcist' pattern — an autonomous AI agent loop that observes, hypothesizes, tests, and patches code without human intervention — is moving from research prototypes into production pipelines at teams shipping to millions of users.

This isn't just "ChatGPT reads your logs." It's a full agentic architecture that fuses static analysis, runtime telemetry, sandboxed execution, and LLM-driven reasoning into a closed-loop debugging system. In this deep-dive, we'll dissect how the Code Exorcist pattern works at the system level, examine real implementation patterns, and look at where it's genuinely useful versus where it still fails.

The Code Exorcist pattern is an autonomous, closed-loop debugging agent that operates on a codebase and its runtime environment. The name is deliberately evocative: just as an exorcist identifies, confronts, and expels an unseen entity, the agent identifies, isolates, and patches an unseen defect.

What distinguishes it from earlier AI-assisted debugging tools (like GitHub Copilot's suggestion engine or early "explain this error" features) is autonomy and action. The agent doesn't just suggest a fix — it executes a structured investigation, generates candidate patches, validates them in isolation, and can autonomously submit pull requests or trigger deployments.

The pattern draws from three lineages:

The core insight is that debugging is fundamentally a hypothesis-driven search problem, and LLMs are surprisingly good at generating and ranking hypotheses — provided they have access to the right tools and feedback loops.

A production-grade Code Exorcist agent isn't a single LLM call. It's a layered system where each layer serves a specific function. Understanding this architecture is critical for both practitioners building these systems and architects evaluating whether to adopt them.

┌─────────────────────────────────────────────────────┐
│                Orchestration Layer                   │
│  (Planner / Goal-Setting / Human-in-the-Loop Gate)  │
├─────────────────────────────────────────────────────┤
│                Reasoning Core                        │
│  (LLM + Hypothesis Engine + Confidence Scoring)     │
├─────────────────────────────────────────────────────┤
│                Action Layer                          │
│  (Patch Generator + Sandbox Runner + Validator)     │
├─────────────────────────────────────────────────────┤
│                Perception Layer                      │
│  (Log Ingestion + Stack Trace Parser + Metrics Feed)│
├─────────────────────────────────────────────────────┤
│                Infrastructure Layer                  │
│  (CI/CD Hooks + Container Runtime + Source Control) │
└─────────────────────────────────────────────────────┘

The topmost layer decides what to debug. It receives triggers (CI failure, alert firing, user-reported bug) and sets goals for the agent. In production systems, this layer often includes a human-in-the-loop gate — a threshold where the agent must for human approval before taking certain actions (e.g., merging a patch to a critical service).

This is the LLM at the center, but augmented with a hypothesis engine that tracks multiple candidate root causes simultaneously, scores them by evidence, and eliminates dead ends. A naïve implementation might just ask "what's wrong?" — a production system maintains a structured belief state.

The agent doesn't just think about fixes; it implements them. This layer includes:

The agent's "senses." This layer ingests:

The substrate: CI/CD pipelines (GitHub Actions, GitLab CI, ArgoCD), container runtimes (Docker, Kubernetes), and source control (Git). The agent interacts with these via standard APIs.

The quality of a Code Exorcist agent's debugging is directly bounded by the quality of its inputs. A common mistake is piping raw log text into an LLM and hoping for the best. Production systems invest heavily in structured observability.

Raw logs are noisy. The perception layer transforms them into agent-consumable formats:

{
  "timestamp": "2026-03-15T14:23:01.442Z",
  "level": "error",
  "service": "payment-gateway",
  "trace_id": "a7f3c2e1-9b4d-4e8f-b1a2-c3d4e5f60789",
  "span_id": "0000000000000042",
  "error": {
    "type": "NullPointerException",
    "message": "Cannot invoke \"com.acme.model.User.getPaymentMethod()\" because \"user\" is null",
    "stack_trace": [
      "at com.acme.gateway.controller.ChargeController.charge(ChargeController.java:87)",
      "at com.acme.gateway.service.PaymentService.processPayment(PaymentService.java:143)",
      "at com.acme.gateway.service.PaymentService$$SpringCGLIB$$0.processPayment(<generated>)"
    ]
  },
  "context": {
    "http_method": "POST",
    "http_path": "/api/v2/charges",
    "user_id": "usr_12345",
    "region": "us-east-1"
  }
}

Modern systems use distributed tracing (OpenTelemetry) to correlate errors across services. The agent receives not just a single error, but a trace waterfall showing where latency spikes, where errors originate, and how services interacted.

The agent needs to understand where the error is in the codebase. This typically involves:

A key design decision is context window management. LLMs have finite context windows, and a monorepo can have millions of lines. The perception layer must prioritize: files touched by the error trace, recently modified files, and files referenced in the stack trace take precedence over the rest.

This is where the LLM does its heaviest lifting — but not as a single monolithic prompt. Production systems use a structured reasoning protocol that breaks the debugging task into sub-problems.

Instead of asking "what's wrong and fix it," the system maintains an explicit hypothesis tree:

{
  "goal": "Fix NullPointerException in ChargeController.charge()",
  "hypotheses": [
    {
      "id": "H1",
      "description": "User object is null because findById() returned empty for invalid user_id",
      "evidence_for": ["Stack trace shows user is null at line 87", "Log shows user_id=usr_12345 which may not exist"],
      "evidence_against": ["findById() should return Optional, not null"],
      "confidence": 0.72,
      "status": "investigating"
    },
    {
      "id": "H2",
      "description": "User object is null due to cache miss race condition in UserCacheService",
      "evidence_for": ["Recent deployment changed cache TTL", "Error correlates with cache eviction events"],
      "evidence_against": ["Error occurs on cold start, not under load"],
      "confidence": 0.35,
      "status": "eliminated"
    }
  ],
  "next_action": "Inspect findById() implementation and UserCacheService configuration"
}

The reasoning core typically follows a structured protocol similar to the ReAct (Reasoning + Acting) or Reflexion pattern:

This is not a single LLM call — it's typically 5-15 calls, with intermediate tool executions between them.

A critical component is calibrated confidence scoring. The agent doesn't just guess — it tracks how certain it is about each hypothesis. This has two practical effects:

LLMs excel at debugging for several structural reasons:

But LLMs have known weaknesses that the architecture must compensate for:

The most technically demanding part of the Code Exorcist pattern is the action layer. Generating a patch is relatively easy — validating that the patch is correct, safe, and doesn't introduce regressions is hard.

The agent generates patches as unified diffs, not full file rewrites. This is intentional: diffs are reviewable, minimal, and easier to validate.

--- a/src/main/java/com/acme/gateway/controller/ChargeController.java
+++ b/src/main/java/com/acme/gateway/controller/ChargeController.java
@@ -84,7 +84,12 @@ public class ChargeController {
     @PostMapping("/api/v2/charges")
     public ResponseEntity<ChargeResponse> charge(@RequestBody ChargeRequest request) {
-        User user = userService.findById(request.getUserId());
+        Optional<User> userOpt = userService.findById(request.getUserId());
+        if (userOpt.isEmpty()) {
+            return ResponseEntity.notFound().build();
+        }
+        User user = userOpt.get();
         PaymentMethod method = user.getPaymentMethod();
         return ResponseEntity.ok(paymentService.processPayment(user, method));
     }

After generating a patch, the agent must validate it. This involves:

This is done in a sandboxed container — typically a Docker container with the full development environment, pre-populated with dependencies. The sandbox is ephemeral: it's created for validation and destroyed afterward.

Generate Patch → Compile → Run Tests → 
  ├─ All pass → Propose for review (or auto-merge if configured)
  └─ Failures → 
      ├─ Test failures indicate patch is wrong → Generate alternative patch
      └─ Test failures indicate existing test issues → Flag and escalate

A sophisticated system will retry with a different hypothesis if the first patch fails validation. This is the "exorcist" loop — it doesn't give up after one attempt.

The Code Exorcist pattern isn't a standalone tool — it's embedded into existing DevOps pipelines. Here are the dominant integration patterns as of 2026:

The agent is triggered when CI fails. It receives the failing build logs, the changed code, and the test results. It investigates and either:

name: Debug Agent
on:
  workflow_run:
    workflows: ["Build and Test"]
    types: [completed]
jobs:
  debug:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Invoke Code Exorcist
        run: |
          npx code-exorcist \
            --workflow-run-id ${{ github.event.workflow_run.id }} \
            --auto-pr \
            --confidence-threshold 0.8

When a production alert fires (e.g., error rate spike, latency degradation), the agent is triggered with the alert context. It investigates the running system, correlates with recent deployments, and may propose a hotfix or rollback.

The agent runs on every pull request before human review. It doesn't just run tests — it performs deep code analysis, identifies potential bugs, and suggests fixes. This shifts debugging left, catching issues before they reach production.

The most advanced pattern: a persistent agent that monitors the system continuously, learns from incidents, and pre-emptively identifies potential failure points. This is the closest to "autonomous DevOps" but carries the highest risk.

Let's build a minimal but functional Code Exorcist agent. This isn't production-ready, but it demonstrates the core architecture.

code-exorcist/
├── src/
│   ├── agent.ts          # Main agent orchestrator
│   ├── perception.ts     # Log and trace ingestion
│   ├── reasoning.ts      # Hypothesis engine
│   ├── action.ts         # Patch generation and validation
│   ├── sandbox.ts        # Docker sandbox management
│   └── tools.ts          # Tool definitions for agent
├── package.json
└── tsconfig.json
js
// src/agent.ts
import { PerceptionLayer } from './perception';
import { ReasoningCore } from './reasoning';
import { ActionLayer } from './action';

export interface DebugTask {
  description: string;
  errorLogs: string[];
  stackTrace: string;
  sourceFiles: Record<string, string>;
  recentCommits: string[];
}

export interface DebugResult {
  rootCause: string;
  patch: string | null;
  confidence: number;
  investigationSteps: string[];
  validated: boolean;
}

export class CodeExorcistAgent {
  private perception: PerceptionLayer;
  private reasoning: ReasoningCore;
  private action: ActionLayer;
  private maxIterations: number;
  private confidenceThreshold: number;

  constructor(options: {
    llmClient: any;
    repoPath: string;
    confidenceThreshold?: number;
    maxIterations?: number;
  }) {
    this.perception = new PerceptionLayer(options.repoPath);
    this.reasoning = new ReasoningCore(options.llmClient);
    this.action = new ActionLayer(options.repoPath, options.llmClient);
    this.maxIterations = options.maxIterations ?? 10;
    this.confidenceThreshold = options.confidenceThreshold ?? 0.75;
  }

  async debug(task: DebugTask): Promise<DebugResult> {
    const investigationSteps: string[] = [];

    // Phase 1: Perception - Gather context
    const context = await this.perception.gatherContext(task);
    investigationSteps.push('Gathered context from logs, source, and git history');

    // Phase 2: Reasoning loop
    let hypotheses = await this.reasoning.generateHypotheses(task, context);
    investigationSteps.push(`Generated ${hypotheses.length} initial hypotheses`);

    for (let i = 0; i < this.maxIterations; i++) {
      // Select highest-confidence uninvestigated hypothesis
      const target = hypotheses
        .filter(h => h.status === 'investigating')
        .sort((a, b) => b.confidence - a.confidence)[0];

      if (!target) break;

      // Investigate: what evidence do we need?
      const evidencePlan = await this.reasoning.planInvestigation(target, context);

      // Gather evidence via tool calls
      const evidence = await this.action.gatherEvidence(evidencePlan);

      // Update hypothesis scores
      hypotheses = await this.reasoning.updateHypotheses(
        hypotheses, target, evidence, context
      );

      investigationSteps.push(
        `Iteration ${i + 1}: Investigated ${target.description} ` +
        `(confidence: ${target.confidence.toFixed(2)})`
      );

      // Check if we have a confident root cause
      const confirmed = hypotheses.find(
        h => h.status === 'confirmed' && h.confidence >= this.confidenceThreshold
      );

      if (confirmed) {
        // Phase 3: Generate and validate patch
        const patch = await this.action.generatePatch(confirmed, context);
        investigationSteps.push('Generated patch for confirmed root cause');

        const validation = await this.action.validatePatch(patch, task);
        investigationSteps.push(
          validation.passed 
            ? 'Patch validated successfully' 
            : `Patch failed validation: ${validation.failures.join(', ')}`
        );

        if (validation.passed) {
          return {
            rootCause: confirmed.description,
            patch: patch.diff,
            confidence: confirmed.confidence,
            investigationSteps,
            validated: true,
          };
        }

        // If patch failed, mark hypothesis as needing revision
        hypotheses = hypotheses.map(h =>
          h.id === confirmed.id
            ? { ...h, status: 'eliminated' as const, confidence: h.confidence * 0.5 }
            : h
        );

        // Generate alternative hypotheses
        hypotheses = await this.reasoning.generateAlternativeHypotheses(
          hypotheses, task, context, evidence
        );
      }
    }

    // Could not resolve autonomously
    return {
      rootCause: 'Could not determine root cause with sufficient confidence',
      patch: null,
      confidence: 0,
      investigationSteps,
      validated: false,
    };
  }
}
// src/reasoning.ts
export interface Hypothesis {
  id: string;
  description: string;
  evidenceFor: string[];
  evidenceAgainst: string[];
  confidence: number;
  status: 'investigating' | 'confirmed' | 'eliminated';
}

export class ReasoningCore {
  private llmClient: any;

  constructor(llmClient: any) {
    this.llmClient = llmClient;
  }

  async generateHypotheses(task: DebugTask, context: any): Promise<Hypothesis[]> {
    const prompt = `
You are a senior software engineer debugging a production issue.

## Error
${task.errorLogs.join('\n')}

## Stack Trace
${task.stackTrace}

## Relevant Source Code
${context.relevantFiles.map((f: any) => `### ${f.path}\n\`\`\`${f.language}\n${f.content}\n\`\`\``).join('\n\n')}

## Recent Commits
${context.recentCommits.join('\n')}

## Task
Analyze this error and generate 3-5 hypotheses about the root cause.
For each hypothesis, provide:
- A clear description
- Evidence that supports it
- Evidence that contradicts it  
- An initial confidence score (0.0 to 1.0)

Respond as JSON: { "hypotheses": [{ "id": "H1", "description": "...", "evidenceFor": ["..."], "evidenceAgainst": ["..."], "confidence": 0.7 }] }
`;

    const response = await this.llmClient.chat.completions.create({
      model: 'gpt-4o',
      messages: [{ role: 'user', content: prompt }],
      temperature: 0.3,
      response_format: { type: 'json_object' },
    });

    const parsed = JSON.parse(response.choices[0].message.content);
    return parsed.hypotheses;
  }

  async updateHypotheses(
    hypotheses: Hypothesis[],
    investigated: Hypothesis,
    evidence: any,
    context: any
  ): Promise<Hypothesis[]> {
    // LLM evaluates new evidence against all hypotheses
    const prompt = `
You are evaluating debugging hypotheses after gathering new evidence.

## All Current Hypotheses
${JSON.stringify(hypotheses, null, 2)}

## Newly Gathered Evidence
${JSON.stringify(evidence, null, 2)}

## Task
Update each hypothesis's confidence score and status based on the new evidence.
- If evidence strongly supports a hypothesis, increase confidence and potentially mark as "confirmed"
- If evidence contradicts a hypothesis, decrease confidence and potentially mark as "eliminated"
- Status should be "investigating", "confirmed", or "eliminated"

Respond as JSON: { "hypotheses": [updated hypotheses with same structure] }
`;

    const response = await this.llmClient.chat.completions.create({
      model: 'gpt-4o',
      messages: [{ role: 'user', content: prompt }],
      temperature: 0.2,
      response_format: { type: 'json_object' },
    });

    return JSON.parse(response.choices[0].message.content).hypotheses;
  }
}
js
// src/action.ts
import { exec } from 'child_process';
import { promisify } from 'util';
import { readFileSync, writeFileSync } from 'fs';

const execAsync = promisify(exec);

export interface Patch {
  diff: string;
  files: Record<string, string>;
}

export class ActionLayer {
  private repoPath: string;
  private llmClient: any;

  constructor(repoPath: string, llmClient: any) {
    this.repoPath = repoPath;
    this.llmClient = llmClient;
  }

  async generatePatch(hypothesis: any, context: any): Promise<Patch> {
    const prompt = `
You are a senior engineer writing a fix for a confirmed bug.

## Root Cause
${hypothesis.description}

## Relevant Source Files
${Object.entries(context.relevantFiles)
  .map(([path, content]) => `### ${path}\n\`\`\`\n${content}\n\`\`\``)
  .join('\n\n')}

## Task
Generate a minimal, correct patch as a unified diff that fixes this root cause.
The patch must:
1. Fix the specific bug without changing unrelated code
2. Not introduce new bugs or regressions
3. Follow the existing code style and patterns
4. Include appropriate null checks, error handling, or validation as needed

Respond as JSON: { "diff": "--- a/file\n+++ b/file\n@@ ...", "explanation": "Why this fix works" }
`;

    const response = await this.llmClient.chat.completions.create({
      model: 'gpt-4o',
      messages: [{ role: 'user', content: prompt }],
      temperature: 0.1,
      response_format: { type: 'json_object' },
    });

    return JSON.parse(response.choices[0].message.content);
  }

  async validatePatch(patch: Patch, task: DebugTask): Promise<{
    passed: boolean;
    failures: string[];
  }> {
    const failures: string[] = [];

    // Step 1: Apply patch to a temp copy
    try {
      await execAsync(`git apply --check <<< '${patch.diff.replace(/'/g, "'\"'\"'")}'`, {
        cwd: this.repoPath,
      });
    } catch (e) {
      return { passed: false, failures: ['Patch does not apply cleanly to current codebase'] };
    }

    // Step 2: Create sandbox container
    const sandboxName = `exorcist-sandbox-${Date.now()}`;
    try {
      await execAsync(
        `docker run -d --name ${sandboxName} -v ${this.repoPath}:/workspace node:20-alpine`
      );

      // Step 3: Copy patched files into sandbox
      await execAsync(
        `docker exec ${sandboxName} sh -c "git apply /workspace/patch.diff"`
      );

      // Step 4: Run tests
      const testResult = await execAsync(
        `docker exec ${sandboxName} sh -c "cd /workspace && npm test -- --bail 2>&1 | tail -50"`,
        { timeout: 120000 }
      );

      // Step 5: Check for specific regression
      if (testResult.stdout.includes('FAIL') || testResult.stdout.includes('failed')) {
        failures.push('Tests failed after applying patch');
      }

    } catch (e: any) {
      failures.push(`Sandbox validation error: ${e.message}`);
    } finally {
      // Cleanup
      await execAsync(`docker rm -f ${sandboxName} 2>/dev/null || true`);
    }

    return {
      passed: failures.length === 0,
      failures,
    };
  }
}
python
// src/index.ts
import { CodeExorcistAgent } from './agent';
import OpenAI from 'openai';

async function main() {
  const llmClient = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

  const agent = new CodeExorcistAgent({
    llmClient,
    repoPath: './my-service',
    confidenceThreshold: 0.75,
    maxIterations: 8,
  });

  const result = await agent.debug({
    description: 'Production error: 500s on POST /api/v2/charges',
    errorLogs: [
      '2026-03-15T14:23:01 ERROR [payment-gateway] NullPointerException in ChargeController.charge',
      '2026-03-15T14:23:01 ERROR [payment-gateway] user is null for user_id=usr_12345',
    ],
    stackTrace: `at com.acme.gateway.controller.ChargeController.charge(ChargeController.java:87)
at com.acme.gateway.service.PaymentService.processPayment(PaymentService.java:143)`,
    sourceFiles: {
      'src/main/java/com/acme/gateway/controller/ChargeController.java': `// ... controller code ...`,
      'src/main/java/com/acme/gateway/service/UserService.java': `// ... user service code ...`,
    },
    recentCommits: [
      'abc1234 - Refactored user lookup to use new cache layer (2 hours ago)',
      'def5678 - Added new payment method support (1 day ago)',
    ],
  });

  console.log('=== DEBUG RESULT ===');
  console.log(`Root Cause: ${result.rootCause}`);
  console.log(`Confidence: ${(result.confidence * 100).toFixed(1)}%`);
  console.log(`Validated: ${result.validated}`);
  console.log(`\nPatch:\n${result.patch}`);
  console.log(`\nInvestigation Steps:`);
  result.investigationSteps.forEach((step, i) => console.log(`  ${i + 1}. ${step}`));
}

main().catch(console.error);

The Code Exorcist pattern is powerful but not magic. Understanding its failure modes is essential for safe deployment.

The agent generates a patch that references APIs, methods, or classes that don't exist in the codebase. This is the most common failure mode.

Mitigation: Always validate patches against the actual codebase via compilation checks. Never trust the LLM's claim that code "exists" — verify it.

The agent correctly patches the symptom but misses the root cause. For example, it adds a null check but the real issue is that the user service should never return null in the first place.

Mitigation: Require the agent to explain the root cause, not just the patch. Human reviewers should evaluate whether the fix addresses the cause or just the symptom.

The agent generates a patch that fixes a bug but introduces a security vulnerability (e.g., adding a debug endpoint, weakening input validation, logging sensitive data).

Mitigation: Run static security analysis (SAST) on all generated patches. Use a separate security-focused LLM call to review patches before they're accepted.

The agent makes a correct local fix but misses system-wide implications. For example, changing a method signature that's used by multiple services.

Mitigation: The perception layer must provide dependency graph context. The agent should be told about callers and dependents of the code it's modifying.

The agent keeps generating patches that fail validation, cycling through the same hypotheses.

Mitigation: Hard iteration limits (the maxIterations parameter). Track previously attempted patches and reject duplicates. Escalate to human after N failed attempts.

The agent reports high confidence in a wrong diagnosis, bypassing human review.

Mitigation: Calibrate confidence scores against historical accuracy. Use conservative thresholds (0.85+) for autonomous action. Always require human approval for patches to critical paths.

The Code Exorcist pattern is still maturing, but the trajectory is clear:

Near-term (2026-2027): Agents will be standard in CI/CD pipelines for well-understood error classes (null pointer exceptions, type errors, configuration mismatches). They'll handle 30-50% of debugging tasks autonomously, with humans handling the rest.

Medium-term (2027-2028): Multi-agent systems where specialized agents handle different aspects — one agent analyzes logs, another examines code, a third validates patches. This reduces context window pressure and improves accuracy.

Long-term (2028+): Continuous debugging agents that learn from every incident, build a knowledge base of the system's failure modes, and pre-emptively fix potential issues before they manifest. This is the "self-healing software" vision.

The key architectural evolution will be in memory and learning. Today's agents start fresh for each debugging task. Tomorrow's agents will maintain persistent knowledge of:

This persistent learning layer is what will transform debugging from an agentic task into an autonomous capability.

The Code Exorcist pattern represents a genuine paradigm shift in software engineering. It doesn't replace developers — it transforms their role from "debugger" to "debugging architect," designing the systems and feedback loops that enable agents to debug effectively. The engineers who master this pattern will be those who understand not just how to write code, but how to make code debuggable by machines.

For developers interested in the broader landscape of AI-powered development tools, Tamiz's Insights covers ongoing analysis of how these patterns are evolving in production environments.

Static analyzers are rule-based and deterministic — they catch known patterns (unused variables, potential null dereferences) but can't reason about novel bugs or cross-service interactions. The Code Exorcist pattern uses LLM reasoning to handle unknown unknowns — bugs that don't match any predefined rule. The two are complementary: static analyzers handle the known patterns at low cost, while the agent handles the complex, ambiguous cases that require reasoning.

As of 2026, a typical debugging task involves 5-15 LLM API calls plus sandbox execution. With current pricing, this runs roughly $0.50-$3.00 per task depending on the model used and complexity. Latency is typically 2-8 minutes end-to-end, dominated by sandbox compilation and test execution rather than LLM inference. Teams running high volumes can reduce costs by routing simple cases to smaller models and reserving frontier models for complex investigations.

It can work with local models, but with significant trade-offs. Local models (7B-70B parameters) can handle straightforward debugging tasks — null pointer fixes, type errors, configuration issues — but struggle with complex cross-service debugging and multi-hypothesis reasoning. Most production deployments use a hybrid approach: local models for initial triage and simple fixes, cloud models for complex investigations. The sandbox validation layer is model-agnostic, so the same infrastructure works regardless of where the LLM inference happens.