Pipelines and agents
A job with consequences breaks into steps: the model drafts, a program checks, the model repairs, a program gates, a person signs. An agent is that same pipeline with the model running the loop, and it needs the same checks.
- The model drafts
- A program checks the draft
- The model repairs what failed
- A program gates the result
- A person signs
Code checks sit between model calls and human sign-off.
Why one prompt is not enough
Ask one prompt to summarize reports, extract the numbers, compute the totals and format a brief, and you have asked for four jobs with no check between them. An error in the second flows into the fourth, the only one you read.
Multi-step work in one prompt also makes the model hold everything at once, which is where it drops constraints. For anything with consequences, one prompt is not a workflow. The reliable pattern alternates the model with deterministic checks and ends with a human.
- Draft
- Check
- Fix
- Gate
- Sign
One job per stage, a check between stages.
| Rule | In practice |
|---|---|
| Anything checkable by a program is checked by a program. | Dates, sums, IDs, references, formats that follow a pattern. |
| One job per call. | "Summarize, then translate, then format as a table" is three calls with a check between each, not one prompt. |
| A second, independent call critiques the first. | "Here is a draft and its sources; list every claim not supported by the sources." Cheap insurance; it is not proof. |
| Keep the human where the consequences are. | The gate before anything goes out is a person with a name on it. |
"Checked by a program" sounds like it needs a developer. Often it needs a spreadsheet: you sum the column of totals; a lookup against the library confirms the instruction references exist. The check is mechanical and independent of the model's opinion of its work.
When to break a task up
| Signal | Split it |
|---|---|
| The output has parts you would check differently (prose, numbers, references) | One call per part, each with its own check |
| The task needs a decision partway through | Stop at the decision; a person makes it; the next call starts from it |
| The input is larger than the model reads evenly | Process sections, then combine |
| The same job runs every week | Write the steps down once; the steps are the pipeline |
| A wrong output would go out under someone's signature | Add the human gate at the end, whatever else you do |
What this looks like without code
You don't need a script. Chat 1 drafts from the attached source. You check every number against the source table. Chat 2, fresh, gets the draft, the source and your list of problems, and repairs it. You read and sign, or don't.
An awards package makes the worked case: four short calls, three checks, and every error has a place it can be caught.
| Call | Does | Check |
|---|---|---|
| 1 | Extracts each nominee's facts from the bios into a table | You check names, rates and dates against the bios |
| 2 | Drafts a citation per row, from the table and last year's approved example | You read two at random against the table |
| 3 | Formats the set into the command's template | A person reads and signs |
Agents, in this frame
An agent is a model given tools and told to keep going until the job is done: read, decide, act, read the result, repeat. It is the pipeline with the model running the loop itself, which removes the pauses where you would have checked.
| A pipeline you run | An agent |
|---|---|
| You decide the steps | The model decides the steps |
| You check between steps | Nobody checks unless you build the check in |
| You act on the result | The agent acts, with whatever tools it has |
| You sign | You still sign, if the gate exists |
The agent builders in these products let you set instructions and give access to files; they do not add checks. Designing an agent asks the pipeline questions: what does it read, what can it do, where is the mechanical check, where does a person sign.
Prompt injection is why the last two are not optional.
What to do with this
Take one recurring task and write its steps as calls and checks. A step with no check is where the next error comes from. Then read Your documents at scale: how the model gets your documents is the other question every recurring task raises.