Where AI Fits in Operations

Language models are unusually good at a set of tasks that resisted conventional automation for decades — and unusually bad at exactly the properties that make conventional automation trustworthy. Getting value from them in operations is mostly a matter of placing them where the first fact matters and the second does not.

The decision framework link

flowchart TD
    A[Task] --> B{Deterministic rule<br/>produces the right answer?}
    B -->|Yes| C["Use conventional automation.<br/>Cheaper, faster, auditable, testable."]
    B -->|No| D{Input is unstructured<br/>language or ambiguous?}
    D -->|No| E["Probably still conventional —<br/>the ambiguity may be a<br/>missing specification."]
    D -->|Yes| F{Is a wrong answer<br/>cheaply detectable?}
    F -->|No| G["Human decides.<br/>Model may assist by summarising."]
    F -->|Yes| H{Does the action need<br/>to be reversible?}
    H -->|Yes and it is not| I["Model proposes,<br/>human approves."]
    H -->|Reversible or verifiable| J["Model can act,<br/>with guardrails and audit."]

The gate that decides most cases is the first one. If a regular expression, a lookup table, or a state machine gives the right answer every time, use it. A model introduces cost, latency, and non-determinism in exchange for flexibility you did not need.

Where models genuinely help link

The pattern across the useful cases: the model handles language, and a deterministic system handles action.

Where models do not belong link

• As the executor of irreversible actions. Deleting data, moving money, changing production configuration. The model can propose; something deterministic and auditable should execute, after approval.
• As the sole detector for anything critical. Non-deterministic detection means a missed detection is not reproducible and not testable.
• Where an audit trail must explain the decision. “The model concluded” is not an explanation an auditor or a regulator accepts.
• Where a deterministic rule already works. Replacing a working regex with a model call is a cost increase disguised as modernisation.
• On unbounded input from untrusted sources, without treating that input as hostile. See Agentic Workflows and Guardrails.

The pattern that works: propose, verify, execute link

sequenceDiagram
    participant S as Signal (alert, ticket, log)
    participant M as Model
    participant V as Deterministic validator
    participant H as Human
    participant E as Executor
    S->>M: context + task
    M->>V: proposed action, structured output
    V->>V: schema valid? action allowlisted?<br/>parameters in range? policy satisfied?
    alt validation fails
        V-->>H: escalate — model produced an invalid proposal
    else validation passes
        V->>H: present proposal with reasoning and evidence
        H->>E: approve
        E->>E: execute deterministically, fully audited
    end

Two design decisions carry most of the safety:

The model’s output is structured data, not a command. It selects from an enumerated set of actions with typed parameters, which a validator can check. A model that emits shell commands has an unbounded action space and cannot be validated meaningfully.

Validation is deterministic and independent of the model. Asking the model to check its own work is not a control.

The retrieval problem link

Most operational value comes from a model reasoning over your context — runbooks, past incidents, architecture docs, recent changes. This is a retrieval problem before it is a model problem, and it fails in a specific way: stale or wrong documents produce confident, wrong answers.

Practical requirements:

• Curate the corpus. Indexing every document in the organization means indexing the outdated ones with equal weight. A small, current, curated corpus beats a large stale one.
• Cite sources. Every answer should link to what it drew on, so the engineer can check. Answers without citations cannot be verified and should not be trusted.
• Include recency and freshness signals, so a document from three years ago is weighted accordingly.
• Prefer structured sources where they exist. The deploy history, the service catalogue, and the metrics API give exact answers; prose gives plausible ones.

Cost and latency are design constraints link

Unlike a script, a model call has meaningful per-invocation cost and latency of seconds. That rules out some placements and shapes others:

• Do not put a model call in a hot path that runs thousands of times per minute.
• Cache aggressively — identical inputs recur far more than people expect.
• Use a smaller, faster model for classification and routing; reserve larger models for genuine reasoning tasks.
• Set explicit budgets and alert on spend. Cost scales with usage in a way script execution does not, and an agent that loops is a runaway invoice.

Adoption checklist link

• Deterministic solutions are exhausted before a model is considered.
• Models handle language; deterministic systems handle action.
• Model output is structured and validated against an allowlist, not free-form commands.
• Validation is deterministic and independent of the model.
• Irreversible actions require human approval.
• Retrieval corpora are curated, current, and answers cite sources.
• Per-invocation cost and latency are budgeted and monitored.