An industry-capable AI process keeps the procedure algorithmic and embeds the language model only as a cognitive step. That is the principle. This article tackles the question of how to draw the line: at which concrete spots may the AI decide, and at which better not?

The Core Principle: Compiled Procedure with Surgical AI

The most frequent mistake in AI projects is to overestimate the share that AI actually has in the solution. If you look closely, the cognitive core of a task is often small; the larger part consists of process control, data access, formatting, and checking. These things classical programming handles more reliably and more reproducibly.

APL, PROSTEP’s AI Pattern Language, draws a clear consequence from this: the procedure is compiled and controlled: sequence, loops, termination, and error handling are laid down in advance, not improvised. AI is not spread broadly over the process, but deployed selectively where its cognitive added value is needed, with clearly defined input and output for a sharply delineated step.

The process then runs because the procedure is described in this way and not because the model reinvents it at runtime. Whether a loop continues should not be freely improvised by the model, but should follow an explicit condition, ideally deterministic. In this way, errors remain local: a poor AI step delivers a poor intermediate result, but does not derail the whole procedure. That is the difference between a process that contains an AI step and one that AI steers.

An Example from Contract Analysis

Contract analysis does not tolerate approximate answers. For an AI process to reliably scrutinize a contract, it has to be precisely steered. That begins with a criteria catalog: a structured collection of check questions that examine a contract in relevant aspects such as liability, termination, warranty, or data protection. The catalog can be adapted according to the type of contract. The actual work, however, is the analysis of an individual question against the contract.

Let us take a question from the catalog:

“Does the contract contain a limitation of liability, and how is it configured?”

Before such a question can be answered, preparatory work has to be done. The contract has to be broken down into individual clauses, and each one stored as an information unit of its own. Each clause has to be classified in domain terms and taken into a semantic and a lexical index.

This analysis step can already be sensibly supported by a language model, by having it generate keywords and extracts. On this basis, an effective hybrid search becomes possible: it finds relevant paragraphs with the help of the indexes, both by term and by meaning, and derives from these a consolidated, ranked hit set. That works more reliably than any direct text analysis by an LLM. Both search paths access clearly delimited, named units, rather than unstructured running text.

The form of the data determines the quality of the process even before the AI has been tasked with actually answering the question. Finding the answer now takes place in three phases:

Search: first, the clauses that match the question are found. AI can help here in a narrowly delimited way with tailoring search terms or search variants to the concrete question. The finding, merging, and ranking of hits, however, remain deterministic. If deterministic ranking is not sufficient to qualify a small set of top hits, AI can take this on as a downstream task.

Evaluation: the language model receives only the clauses identified as relevant and answers the question against them: whether a limitation of liability is present, how it is formulated, which exceptions apply, and what effect it has. Understanding text and relating it to a concrete question is the part that AI does well. What is decisive is that it is clearly instructed to judge only on the clauses put before it, and not from free memory.

Recording: the answer is captured in a structured way, with a reference to the source clauses from which it was generated. After that, it can flow into a report, an overall evaluation, or a comparison.

Over this individual analysis lies the loop: the process works through the catalog question by question, with visible and reproducible intermediate results. The AI contributes here only a few, sharply delineated touches per question: sharpening search variants, evaluating clauses in a final relevance judgment, formulating answers. But which question comes next, and when the catalog is complete, is determined by the procedure, not by the model.

The fact that every answer refers back to its source clauses makes the process verifiable. If an answer seems questionable, you can see at a glance whether the search already delivered the wrong clauses or whether only the evaluation went astray, without having to follow an opaque chat history.

But Doesn’t an Agent with Enough Tools Suffice?

A natural objection is why the compiled procedure is needed at all. One could, after all, simply give an autonomous agent enough deterministic tools for search, storage, and report generation, and let it decide for itself when to call what. The catch is that deterministic tools do not yet yield a deterministic process.

Deterministic tools make individual actions reliable. What remains open, however, is the orchestration, i.e. which tool is called when, how often a step is repeated, which intermediate results count, and when the process is finished. If you leave this control to the language model, the procedure emerges anew at runtime each time. That is what a language model does least reliably.

From this follow three practical problems:

Reproducibility: the same question and the same contract can, with a freely orchestrating agent, produce two different paths and two different answers. A described procedure takes the same path every time. For a legal review, “mostly right” is not enough.

Reviewability before execution: a described procedure can be read and released before it runs. With a freely orchestrating agent, the path only emerges at runtime, and anew with every run. There is nothing to review in advance, only a trace afterwards.

Local, rather than global errors: a misjudgment about an individual clause remains local in a described procedure. A misjudgment about the sequence, e.g. an evaluation without a preceding search, is a global error that devalues the entire result.

That does not mean the freely orchestrating agent is never the right choice. For open, exploratory tasks it is precisely the right choice (more on this in a later article). But for processes that must reliably, verifiably, and repeatably do the same thing, control over the procedure belongs in a deterministic backbone, not in the hands of the model.

Where the Line Runs Is Found Empirically

That leaves the question of how one knows which spot should be an AI step and which a deterministic one. Unfortunately, the question cannot be answered theoretically. The boundary has to be found empirically for every use case.

A step that you initially leave to the model turns out to be deterministically solvable once you have understood the pattern, and becomes more reliable when you rebuild it. Conversely, a supposedly simple rule-based step can hit its limits with more variable input data and, in the end, need AI. In the contract example, the selection of relevant clauses can, with cleanly structured contracts, largely succeed via search and ranking; with less uniform contracts, an additional AI step may become necessary that curates the hit list against the question — or vice versa.

Precisely for this reason, the clean separation pays off. Because APL does not mix process logic, cognitive steps, and deterministic actions, this boundary can be shifted in a controlled way without rebuilding the process. You adjust one spot, not the whole. That is the practical core of industry-capable AI: a process becomes industry-capable not through the model taking over as many decisions as possible, but through every decision being in the right place.

The next part of this chapter leaves the internal view of the process and shows how APL does not place the agents next to an application, but incorporates them into the application.