AI can be remarkably effective at turning vague, manual work into software. But that does not mean an AI model should execute the resulting workflow forever.

A common anti-pattern is to use an AI agent as the runtime for stable business logic: reading the same kind of file, rediscovering its structure, applying known mappings, and generating the same kind of output on every run.

The first demo may look impressive. Repeated in production, it becomes expensive, fragile, difficult to test, and hard to govern.

Context

This pattern appears in repeatable work such as file transformation, CSV or Excel processing, data mapping, schema validation, reference-data lookup, and template configuration.

A typical workflow accepts a file and some known context—such as a site, market, customer, or product—then applies established rules, validates the result, and returns a configured output file.

These are primarily workflow and contract problems, not reasoning problems.

The Anti-Pattern

The anti-pattern is using an AI model as the execution engine for deterministic business logic.

Each run asks the model to rediscover the same structure, reinterpret the same rules, inspect the same reference data, and reconstruct the same transformation. The system consumes tokens as if the problem were new, even though the workflow is stable.

Stable, repeatable transformations should be implemented as deterministic workflows, not repeated AI reasoning sessions.

Why It Fails

  • High marginal cost: every run spends tokens on parsing, reasoning, and validation.
  • Poor determinism: the same input may not reliably produce the same output.
  • Hidden business logic: rules live in prompts and examples instead of reviewable code and configuration.
  • Weak validation: correctness depends on model behavior rather than explicit, testable contracts.
  • Limited control: failures are harder to reproduce, debug, audit, and explain.

The deeper problem is that the design confuses discovery with execution. A successful proof of concept is mistaken for a sustainable architecture.

The Better Pattern: Compile the Workflow

Separate design-time AI assistance from runtime execution.

At design time, use AI to:

  • understand the existing manual or spreadsheet-based workflow;
  • identify schemas, mappings, rules, and edge cases;
  • generate parser and transformation code;
  • create validation tests and documentation.

At runtime, use deterministic software to:

  • parse the input;
  • validate required fields and schemas;
  • look up governed reference data;
  • apply known mappings;
  • produce the output and a validation report.

The implementation might be a script, web application, serverless function, workflow step, or agent action. The form is secondary. The important part is deterministic execution behind a stable contract.

Example

Suppose a spreadsheet performs site-specific file configuration.

The wrong solution is an agent that repeatedly reads the spreadsheet, interprets reference files, reasons about the necessary changes, and generates a CSV.

The better solution is to reverse-engineer the logic once, define the input and output schemas, move reference data into governed configuration, implement the transformation in code, and add tests. An agent may still provide the conversational interface, but it should call the deterministic workflow rather than embody its logic.

When Runtime AI Is Appropriate

AI still belongs at runtime when the task requires genuine interpretation:

  • the input is novel or its structure changes constantly;
  • the output requires judgment, summarization, classification, or explanation;
  • the workflow is exploratory and has not stabilized;
  • codifying deterministic rules would cost more than repeatability is worth.

Once a workflow stabilizes, move it from repeated reasoning into deterministic execution.

Detection Signals

You may be using this anti-pattern if people say:

  • “The agent needs to understand the spreadsheet every time.”
  • “It works when I explain it carefully.”
  • “Sometimes it creates the file correctly.”
  • “We need more prompt guardrails.”
  • “It consumes many tokens, but the task is always the same.”

Rule of Thumb

If the same input, reference data, and context should always produce the same output, the runtime should be deterministic.

Use AI to build the machine, not to act as the machine.

The goal is not to spend tokens forever. It is to convert repeated reasoning into reusable capability.