Chapter 1 - From Prompt to Workflow

THE FIRST FAILURE IS CONFUSING A GOOD OUTPUT WITH A GOOD SYSTEM

Northstar Services did not begin with an AI strategy. It began with a coordinator who was tired of reading the same kinds of client-change requests every morning. Requests arrived through a form, email, and occasionally a message forwarded from an account executive. The coordinator copied each request into an AI assistant and asked for three things: a summary, a recommended category, and a suggested owner. The results were good often enough that the practice spread.

Within two weeks, the team was calling the process “AI triage.” That label hid the real condition. The AI had no reliable access to the current contract, did not know which account tier controlled response targets, could not distinguish a defect from a scope change when client language was vague, and had no authority to write the route back to the service system. The coordinator compensated using memory. When another person covered the desk, the same prompt produced different operational outcomes because the surrounding human work was different.

The prompt is an interface, not the workflow

A prompt can specify a task, but a workflow must also specify where the task begins, what information is authoritative, what state exists before and after the task, what may change, what requires approval, how exceptions are handled, and how the result is measured. These elements are easy to ignore during experimentation because the human operator silently supplies them. Scaling removes that hidden support.

The distinction matters even if the organization never builds a complex agent. A manually initiated AI step can still be a controlled workflow. Conversely, an automated sequence of model and tool calls can still be operationally weak if its inputs, authority, and evidence are ambiguous.

Start with the job to be done

Northstar reframed the objective from “use AI to triage requests” to “move each client-change request from arrival to an evidence-backed route within the service-level target, without creating unauthorized scope commitments.” The second statement is longer because it contains the business outcome and the primary failure condition. It also makes several design questions visible: what counts as arrival, what is a route, what evidence is required, which service-level target applies, and what would constitute an unauthorized commitment?

Separate proposal from authority

Generative systems are valuable because they can operate under ambiguity. That is also why their output should usually enter the workflow as a proposal rather than an unexplained fact. Northstar decided that the AI could propose a classification, summarize evidence, and draft a routing rationale. Deterministic rules could calculate the service-level target. A named service coordinator could approve ordinary ambiguous routes. Only an account owner could decide that a request represented billable scope outside the current agreement.

This split prevented a common design error: granting authority merely because the model appeared competent. Capability is empirical and can change with the model and the task. Authority is organizational and should change only through an explicit decision.

Define the boundary before optimizing the middle

The Northstar workflow begins when a request receives a workflow ID and the required client/account identifiers can be resolved. It ends when an approved route is written to the service system and the originating request is linked to that record. If the request cannot be resolved to an active account, if required contract evidence is unavailable, or if the request appears to contain a security incident, the workflow exits to an exception path rather than improvising.

That boundary sounds procedural, but it protects measurement. Without it, the team could claim faster triage while quietly excluding difficult cases. A defined start and end allows the denominator to include the work the organization actually receives.

Figure 1. Prompt-to-Workflow Control Path

What Northstar learned in the first week

The original AI prompt was not discarded. It became one component inside the redesigned path. The team retained the useful summary format and category suggestions, but moved contract retrieval, deterministic service-level logic, authority, state, and evidence into explicit workflow elements. The coordinator stopped being the invisible system integrator.

This is the central move of the book: do not ask the model to absorb the operating system into a prompt. Put the operating system around the model so the model can be changed, tested, constrained, or removed without losing ownership of the work.

Questions to answer before proceeding

What business outcome defines success?

What event starts the workflow, and what event ends it?

Which outputs are proposals, which are calculations, and which are decisions?

What actions can change a system of record?

What conditions force the workflow to stop or escalate?

What evidence must survive after the work is complete?

What belongs in a workflow specification

A reusable prompt is useful, but it is not sufficient as the governing artifact. Northstar created a workflow specification that sits above the prompt. The specification names the trigger, accepted inputs, context sources, D/R/G/H steps, states, approval rules, write permissions, evidence requirements, stop conditions, tests, and measures. The prompt is referenced as one versioned component. That relationship matters because a prompt can change while the business contract remains stable, or the business contract can change in a way that requires several components—not only the prompt—to change.

This separation also helps technical and operational teams work together. The workflow owner can state that a potential scope commitment must never be executed without account-owner approval. The technical team can decide whether the implementation uses a queue, policy engine, orchestration service, or other mechanism. The business requirement remains legible even if the technology stack changes.

Boundary test: five requests that reveal the design

Northstar tested the workflow boundary with five intentionally different requests. A complete routine request should enter Submitted immediately. An email with no account identifier should enter Submitted but fail validation into Exception: Identity Unresolved. A message reporting suspected credential theft should be diverted to the security incident process rather than continue through ordinary routing. A duplicate submission should resolve to the existing workflow ID or be rejected as duplicate. A request from an inactive account should stop before any contract or client data is retrieved. These cases turned “start of workflow” from a diagram into observable behavior.

The end boundary received similar tests. A successful API call was not enough. A case ended only after the target record existed, the route matched the approved class, the workflow ID was linked, and the required acknowledgment was either sent or deliberately suppressed with a reason. That prevented technical completion from being counted as business completion.

Three early anti-patterns

The first anti-pattern is prompt sprawl: each user maintains a slightly different version of the “good prompt,” creating multiple unofficial workflows. The second is hidden authority: a person approves model output by editing it in place, but the system cannot distinguish a factual correction from a business decision. The third is anecdotal success: the team remembers impressive examples and forgets the hard cases that required manual rescue. Northstar countered these by versioning the operating specification, recording approval as a separate event, and measuring the full case population.

A useful implementation test is to ask a new operator to explain the workflow without seeing the prompt. If the person cannot describe the trigger, states, approval boundary, exception behavior, and measure of success, the operating design still depends too heavily on tacit knowledge.