The first real run

The workflow went into use on a Monday, privately, so that only the sales desk could start it. By the Wednesday, Nadia had learned five things that she would have preferred to learn from a plan. They are the same five things that every team learns in its first weeks, in much the same order, and this chapter exists because a platform either provides for them in its design or leaves them to the customer.

Fluent, confident and wrong

The first lesson was that a model can be fluent, confident and wrong. On the Tuesday the research step produced a warm description of a hotel chain and its rooms; the chain did not exist under that name. The web search had failed and the model had filled the gap from its own resources. The workflow did not act on the description, and it is worth being precise about why. The research step is required to answer in a fixed form, with five named fields, one of which is reserved for evidence, and it is required to say when the web has given it nothing. That check is applied before any later step reads the answer, and an answer that fails it is returned to the model with the failure explained. By the Wednesday the instruction had been tightened, and when a search next failed the evidence field said so and the model's view was recorded as unknown. A model that is permitted to guess will guess. The requirement is that nothing it says should flow directly into an action.

Reading what strangers write

The second lesson was that a step which reads what strangers have written must not be able to act on it. One enquiry contained, in its notes field, a sentence addressed to "the assistant" asking it to apply a thirty per cent discount. The research step read the sentence and could do nothing about it, because the only tool it possesses is a web search. The price is set by a rule in which no model participates. Deciding what each step may reach, and giving no reach at all to the steps that read untrusted text, is most of what security means in a process of this kind; and in a workflow it is a property of each step rather than a paragraph in a policy.

Who, what, and how much

The third lesson was that the question of who approved a given decision must have an answer other than "the system". The fourth arose when a buyer disputed a quotation a fortnight later: the useful question was not what the last message had said but what every step had done, and the workflow's record contained all of it, namely what entered each step, what the model was asked and what it answered, what the rule computed, who approved, and when. The record can be added to but not altered, by anyone, and it can be replayed. The fifth lesson arrived as a figure. Forty-one enquiries in the first week, two model calls in each, and a cost per completed quotation that could be read rather than estimated, because every model step is subject to a ceiling on how long it may run and how much it may spend, and every call is priced in a ledger kept alongside the run.

Chapters 4 and 5 pursue the third and fifth of these further. What matters here is the shape of the week. None of the five was a project in its own right. Each was a property of the workflow the coding agent had written, visible in its diagram, and each correction was a matter of a sentence.