5 min

Filling in what the form did not ask

A lead arrives with four fields filled in. Before anybody calls them, an agent goes and finds what the form did not ask for — and is told exactly what it may not invent.

A web form gets you a name, a number, an email and a city. An advisor picking up the phone wants rather more than that, and spends the first four minutes of the call getting it. This workflow spends those four minutes before the call, without anybody in the room.

The shape: fetch, decide, write

2.1 · Fill in what's missing on a new lead

A new contact appears, a search goes out, an agent reads what came back, and the contact record is updated with the result.

Results

Scroll for all 4 steps →

Two of the four boxes are ordinary and one is not. The trigger and the write are the same kinds of box you read in Module 2. The search is a plain lookup. Only the Core Agent in the middle is doing something a rule could not do — and knowing which box that is, in any workflow, is most of what a partner needs to explain.

It searches for a person, not a keyword

Look at what the search is actually given. It is built out of the record that just arrived — the name, and the city they said they were in — rather than a fixed phrase:

The search query is assembled from the trigger's own fields. Same {{ }} mechanism as everywhere else. Nothing here is special-cased for search; it is a node whose configuration happens to be a sentence.

What the agent may write, and what it may not

This is the part to read properly, because it is the answer to the question every client asks about AI on their data.

enricher — ## Constraints

## Constraints
- **Leave a field blank rather than guess.** A wrong employer on the record is
  worse than an empty one: it gets repeated back to the customer.
- Never infer income, creditworthiness or eligibility. Those come from
  documents, not from the internet.
- Do not record anything about family, religion, caste or health.
- If nothing matches confidently, write only the summary line saying so.
- Never call write_back without the entity_id. Writing without it creates a
  duplicate contact instead of updating this one.

From the agent's real prompt, as saved in your org.

The agent is not trusted, it is bounded. The limits are written in English, by a person, in a box anyone on the team can open and change. When a client asks “what stops it making things up about our customers?”, this is the screen to show them — not a claim about the model.

Why the write is a separate box

If the agent wrote directly	Why it does not
The model would decide which record to update.	The record is fixed by the workflow: `entity_id` comes from the trigger, so the update can only land on the contact that just arrived.
You would have to trust its output was well-formed.	The write is an ordinary `CRM Manager` node with a schema. It fails loudly rather than writing nonsense quietly.
There would be nothing to read afterwards.	The write is its own step in the run record, with its own inputs and outputs.

The model would decide which record to update.

Why it does not: The record is fixed by the workflow: entity_id comes from the trigger, so the update can only land on the contact that just arrived.

You would have to trust its output was well-formed.

Why it does not: The write is an ordinary CRM Manager node with a schema. It fails loudly rather than writing nonsense quietly.

There would be nothing to read afterwards.

Why it does not: The write is its own step in the run record, with its own inputs and outputs.

The agent decides; the workflow acts. That separation is the single most repeated pattern in this org, and it is what makes an AI workflow auditable rather than magical.

Change one thing

Edit the boundary, not the behaviour. Everything you can safely change on this workflow is a sentence in English, and that is the point of the exercise.

Open the agent and read its Constraints out loud. That is the compliance conversation, already written.
Add one line to the Constraints — something you would want a client's version to refuse to do. Save.
Open look_them_up and read the query. Say which part of it came from the lead and which part the builder typed.
Do not run it yet. This one costs a web search and a model call every time it fires, and The execution log: run one, then read it already taught you how to read what it did.

Try it

Find the other workflows in the org with the same fetch-decide-write shape. There are several, and spotting the shape is faster than reading them.
Ask yourself what this workflow does if the search comes back with nothing useful. Then read the Constraints again and see whether it is answered.

Next: Scoring a lead against a written rubric — the same shape again, with the agent scoring against a rubric a human wrote and can argue with.

Try this in Expedify →

Related lessons

12 min read

Base rates — what a piece of evidence is actually worth

A face-recognition system that is 99.9% accurate and almost entirely wrong, and a number that sent an innocent woman to prison. Both are the same arithmetic, and it is the arithmetic that decides what any piece of evidence is worth.

Read

10 min read

Confirmation and survivorship — what you never looked for

Two questions about evidence you did not go looking for. One is a rule you have to discover, and one is a pattern in five famous people — and in both, the thing that would have told you the truth is the thing nobody checks.

Read

14 min read

Loss aversion, sunk cost and regression — what it costs you

Four questions you answer about yourself rather than about a scenario, and your own answers are the finding. Then the pattern that makes praise look useless and criticism look like it works, whatever you actually do.

Read