This article explains a problem that sits underneath most reliability failures in AI automation, and that is often mistaken for a problem with the model: the instructions themselves are ambiguous and incomplete. It describes why that is unavoidable, why a language model cannot compensate for it, and what a platform has to do instead.

1: Why every procedure has gaps

A standard operating procedure is written by people who know the business, for people who will learn the business. It can afford to be short because its readers bring a great deal with them: training, the habits of their team, the memory of how last month's unusual case was handled, and a manager they can ask. Procedures therefore leave out what "everyone knows", use terms they do not define ("promptly", "high-risk", "the original payment method"), describe the normal case and not the exceptions, and are written separately from the systems they describe, so the two sometimes disagree.

None of this is carelessness. A procedure that tried to settle every case in advance would be unreadable. But it means that a procedure, taken literally, does not determine what to do in a large share of real cases.

2: Why a language model cannot compensate

A trained employee who meets a gap does one of three things: applies how such cases have been handled before, asks someone with authority, or flags the case. In each case the answer comes from outside the text, and once given, it is reused.

A language model given the same procedure does none of these.

• It does not know a gap exists. A model reads an ambiguous sentence as having some meaning, and acts on that meaning. Nothing in its output says "I had to choose here".

• It fills the gap with a plausible guess. The guess is drawn from what is generally likely, not from what this business decided, because that decision is not in its input.

• Its guesses vary. The same gap, met on two similar cases, can be filled two different ways. This is a major source of the inconsistency described in How to measure whether an AI-automated process is reliable.

• A more capable model guesses more fluently, not more correctly. The correct answer is a business decision. A better model can be better at noticing that a sentence is ambiguous, if asked, but it cannot know which reading the business wants.

Prompt wording cannot fix this either. Rephrasing an instruction can make one reading more likely, but it does not decide the question, and the decision stays buried in text that the model will interpret again on the next run.

3: What the gaps look like in practice

The τ²-bench retail work started from a short written store policy and the contracts of the store's tools. Turning them into a reliable process surfaced questions like these.

• Silence. When a customer exchanges an item for a different color, what happens to the options they did not mention, such as size? The policy says nothing. One reading is that unmentioned options are free; another is that they stay as they are. The process owner decided that the customer chooses: when several items meet everything the customer asked for, all of them are shown with what each one changes.

• Contradiction. The policy allows a transfer to a human "if and only if" the request cannot be handled within the agent's actions. The transfer tool's description says to transfer when the user explicitly asks. The policy wins, and the process records that a request for a human does not by itself change what the request is.

• Policy against practice. For a request outside the agent's actions, such as placing a new order, the policy implies a transfer, while the expected behavior is to say plainly that it cannot be done and carry on with the rest. Where the policy and the expected behavior differ, the process owner clarified the policy.

• An undefined boundary. The policy forbids "subjective recommendations" but does not say whether suggesting an action the customer did not ask for is one. The owner decided that the agent answers what was asked and does not propose unrequested changes.

None of these questions can be answered from the text. Each one, left to the model, would have been decided differently on different calls.

4: What the platform has to do instead

If the gaps cannot be closed at run time by the model, they have to be closed at design time by the business, and the platform has to make that practical. In Thunk.AI this happens in four parts.

Turn the procedure into an explicit specification.

Every sentence of the procedure and of the system contracts that constrains an action becomes a rule. Every dimension of an action that they leave open becomes an open point. The τ²-bench specification has nineteen rules and five open points, each citing the sentence it came from. This step is where gaps become visible: a rule that cannot be stated precisely, or two rules that conflict, is a question for the process owner. In Thunk.AI this happens in the Authoring Environment, and the Forward Deployed Agent automates most of it. The Forward Deployed Agent, which runs in Claude or ChatGPT, reads the procedure and the contracts of the systems involved, derives the rules and open points, and brings each gap or conflict it finds to the process owner as a question instead of settling it with a guess. It then builds each decision into the thunk with the mechanism that fits it, and tests the result. In the τ²-bench work, the specification was derived this way, by an AI agent working through the Thunk.AI Builder, with every question decided by the process owner.

Have the process owner decide, and record the decision.

Each question gets a recorded decision with its reason, as part of the process definition, not as an extra sentence in a prompt. The record matters: when a decision later turns out to be wrong, it can be found and changed in one place. In the τ²-bench work, the decision about unmentioned options was itself revised after a review of two failed tasks, and the revision is recorded next to the original.

Enforce each decision with a mechanism, not a sentence.

A decision written into the directions is read and interpreted again on every run. A decision built into the process is applied exactly. The option-handling decision became a search tool that returns every item meeting the customer's stated requirements and marks the one that keeps the current values. The transfer decision became an AI tool that only judges whether a request is within scope, and a code tool that performs the transfer only when that judgment allows it. What is in a standard operating procedure, and how each part is made reliable describes the mechanisms.

Give the agent a way to say the information is missing.

Some gaps only appear at run time, in a particular case. The platform has to make "I cannot decide this from what I have" a legitimate outcome: an explicit value for missing information, a request to a person, or a step that cannot finish until a required fact is present. Without that, the model invents.

5: Over-constraining is a failure too

It is tempting to close every gap with a rule. Some gaps are deliberate: the procedure leaves the choice to the customer or to the person doing the work. In the τ²-bench work, the first versions of the design added rules the policy did not contain. One defaulted the payment method for a refund when the policy says the user must provide one. Another had the order lookup decide whether an order matched the customer's description and ask the customer for an order number, when the policy says the agent should help the customer look the order up. Both were found by reviewing the design against the policy, and both were removed.

An open point is recorded as open, and the platform offers capabilities for it instead of rules: a tool that lists the customer's addresses or orders, or computes the candidates for a choice, without making the choice. The aim is a process that is exactly as constrained as the business intends, no more and no less.