Tools copy the form and load the guide; models fill the arguments

Making a quote from a company form takes two steps: copy the form to a new path, then fill in the copy. If copying is a separate tool the model has to call, the model often skips it. The edit then fails with "target file not found," or the model passes the form's own path as the edit target and the original is changed in place. The next person who opens that form finds the last customer's name and amounts already in it. Reading the format's working guide before building a document has the same shape, and it gets skipped the same way.

These steps have the same right answer every time. A form always has to be copied, and a model building a Word document always needs the Word guide. So OwlAI does not leave these steps to the model; the tool does them inside the call. The model is asked only about what differs from case to case, as an argument of the call it is already making. This post covers which steps we moved inside the tools and what we ask the model, in what form.

#The model skips steps it has to call separately

The common approach is to write the order into tool descriptions and the system prompt: "Copy the file with the copy tool before editing," "Load the guide before creating a document." The sentences are clear. They are followed far less often.

We measured this in one production install. With a separate tool for loading guides and a note in its description saying to load it first, the tool ran 6 times in 3,955 turns between April 27 and August 5, 2026. Over the same period, 53 turns produced a reporting document that had a guide without ever reading it. With one more paragraph at the top of the guide list explaining how to load a guide, the same install's count on September 7, 2026 was 76 calls in 14,773 turns, or 0.5% of turns.

Over the same period, the tool that activates other tools ran 1,255 times. Both are called on demand, and the gap has one cause. Without activating a tool, the model can do nothing; without reading a guide, the document still gets made and the answer still goes out. A step that can be skipped without blocking the result gets skipped, however the sentence is polished. Copying a form has the same shape. An edit that missed the copy fails only afterward, and an edit aimed at the original path does not fail at all.

#Guides arrive with the tools that need them

OwlAI does not show many tools, such as the document and file tools, to the model up front; the model picks them by name and activates them (“185 tool definitions cost 99K tokens, so we list names and load picks”). We attached guides to that activation step. The activation tool returns, in its result, the full text of the working guide linked to each tool it just activated. Activate the Word editing tool and the Word editing guide arrives in the same result. The model never gets a turn to choose whether to read it.

A guide lists where files of that format break and how to avoid it. For example, when you copy a PowerPoint template (.potx) to .pptx to edit it, the document-type marker inside the file has to change too. Otherwise PowerPoint keeps opening the copy as a template. Shipping the guide keeps the model from building documents without knowing rules like this.

The guide is sent again every time a tool is activated. When a long conversation is compacted, older results are removed, and if we skipped "already sent" guides, a guide removed that way would never come back.

#The edit tool copies the form through a template argument

The Word, PowerPoint, Excel and Hangul (hwpx) editing tools take an optional template argument. Given a form's path, the tool copies the form to the output path path, and the edit code the model wrote runs against that copy. The model's edit target is the copy; the form file is only where the copy starts. Filling a form becomes one call to the edit tool.

Whether template is given and whether a file already sits at path fixes the outcome to one of four.

The last row is refused because that path may hold a document this conversation has already handed to the user. Whether the model means to start over from the form or to keep editing the document it just filled is something the model has to say. If the tool picked one, the other document would vanish without a signal.

There was a way without a new argument: "editing a path that does not exist reads the form and writes a new file." That keeps the schema one argument smaller. But under that rule the same call is an edit when the file exists and a creation when it does not. You cannot tell which from the call alone, so we did not adopt it.

The following cases are refused before any edit code runs. Refusing afterward wastes a model call and leaves a half-made file in the user's work folder.

• The form path has no file.
• The extension does not match the tool's format. Each format accepts only its own extension and its template extension (.docx and .dotx, .pptx and .potx, .xlsx and .xltx; Hangul takes .hwpx).
• The file is a macro-enabled variant. The output extension is the macro-free format, so accepting it would ship a file whose macros have disappeared.
• template is passed to a create tool, which starts a new document. The create tools' schemas do not have this argument, so a request that came with a form never gets a blank document.

Reading the form stays with the model. Fill a form without knowing its structure and you overwrite label cells such as "Customer name" with values. So the edit tool's description tells the model to look at the form first with the read tool for that format. Which cell gets what is a judgment that needs context; copying is an action with exactly one right answer.

#In a playbook, the runner copies before the model starts

A playbook is a procedure saved as steps that runs a recurring task without a person. A playbook's document step already knows the form path and the output path from its settings. So the playbook runner copies the form to the output path before calling the model, and gives the model only the edit tool and the read tool for that format.

We did not use the template argument here, as chat does, because of the number of paths the model holds. When the runner copies first, the read tool and the edit tool point at one path. Passing template would split it into a path to read (the form) and a path to write (the output). In a run with no person and no screen check, there is no reason to hand the model one more path. The methods differ, but in both chat and playbooks the copying is done by code.

#Filling a few cells takes a cell list argument

Most requests to fill an Excel form come down to "this value in this cell." If the edit tool accepts only code, the model writes a fresh zip and XML script on every call just to fill a few cells. In production on October 1, 2026, one call that filled a quote form took 161 seconds and 22,000 output tokens.

So the Excel editing tool takes a cell list instead of code. Each entry gives a sheet, a cell address and a value; a value marked as a date is written as an Excel date. Combined with template, copying the form and filling its values happen in one call with no script. These cells are refused before anything runs:

• A cell that holds a formula. The error points the model to the input cells the formula reads.
• A cell inside a merged range other than its top-left cell.
• A table header cell.
• A value outside the cell's dropdown list. The error lists the allowed values.

Everything other than the worksheets stays byte for byte. Cached formula results are cleared so that Excel recalculates when the file is opened.

#The tool also says what to do after a failure

When the next move after a failure is the same every time, the tool writes that move into its result too.

If the edit code fails while filling from template, the tool restores the copy to the form's state and does not delete it. Calling again with the same arguments would then be refused with "a file already exists." So the error message names the exact fix: "call again with the same path and without template." Deleting the copy would have made the retry identical to the first call, but it would also throw away a copy already made.

When a chart widget tool fails validation twice in a row within one turn, the server changes the instruction in the result from "retry" to "present a table," and returns the rows and columns the model had passed. The model does not have to make the data up again, and the user sees a table instead of an error message.

#Case-by-case judgments are asked as arguments with no default

Judgments whose right answer changes from case to case stay with the model. The nine document-creating tools and the file copy tool take an attach argument. It decides whether a file goes to the user as a download card or stays as an intermediate file the model will read back. Only the model, having read the user's request, knows the answer.

This argument has no default; it is required. A default would make the decision in the model's place, and whichever way it was set, one kind of failure would go unnoticed. With a default of "attach," debug files pile up as download cards; with "do not attach," the file the user asked for quietly disappears.

The evidence that the model can make this call is also measured. In production, we checked the 77 calls in which the file copy tool used attach against their conversations, and one was wrong. All 47 copies made from a form were left unattached, and 29 of the 30 copies of a finished deliverable were attached. Calling a separate tool first happened in 0.5% of turns, while choosing one argument of the call already being made was right in 76 of 77 cases. So when we leave a judgment to the model, we ask it as a required argument of that call, not as a separate call.

Whether to pass template is also the model's choice, because some requests want a blank document drawn from scratch even when a form exists.

#Design choices

Each step moved inside a tool makes the schema and the result larger. Every argument needs its meaning and refusal conditions in the description, and that description costs tokens on every call. Guide text is sent again on every activation, so the same guide can appear twice in a conversation. That is why we only move steps inside a tool when the right answer is the same every time and measurements have shown the damage when the step is missed: an original form changed in place, documents built without their guide, 161 seconds for a few cells.

template accepts only each format's own extension and its template extension. Macro-enabled documents are not accepted, so to fill such a form the model makes its own copy with the copy tool and then edits without template. This is the only case where the model still does the copying. We preferred it to shipping a file whose macros vanished without a signal.

Because a failed edit's copy is kept, the retry's arguments differ from the first call's. The error message points out the difference, and the model continues editing the copy that already exists.

The cost of making attach required is one more argument for the model to fill on every call. In return, the decision is always the model's.

If you run document tools that fill forms or have to follow format-specific rules, look first for the steps in your prompt that can be skipped without blocking the result. If such a step has the same right answer every time, move it inside the tool instead of polishing the sentence, and ask for whatever judgment remains as an argument with no default.