Building an agent by asking

Lesson 36 of 40 · 6 min

The last lesson built something that follows rules. This one builds something that decides, and almost everything about the exercise is different — not harder, but different in what you have to get right.

It starts by asking what is available

You: What knowledge bases have we got?

Three came back, and the one this agent needs is the customer-facing one — not the internal playbooks. That choice is the first real decision of the build, and it is the one from Giving an agent a knowledge base: the workflow pins which knowledge base the agent can reach, and the agent cannot argue with it.

Then the whole agent, in a sentence

You: Build me an assistant that answers customer questions from the customer handbook, and refuses to quote rates or promise approval.

Read that ask again and notice what is in it. Not a structure — a job: who it answers, what it answers from, and what it must refuse. That is what an agent is made of.

"node_count": 3,
"status": "draft",
"warnings": []

From the capture on 2026-08-19.

Three nodes, and only one of them is a step

The shape you first met on the canvas in Module 3, built from a sentence.

Node	What it is
The trigger	A message arrives. The entry point, same as any workflow
The agent	The only thing in the flow. It reads the message and decides
The knowledge base	Attached to the agent, not chained after it — a tool it may reach for

The trigger

What it is: A message arrives. The entry point, same as any workflow

The agent

What it is: The only thing in the flow. It reads the message and decides

The knowledge base

What it is: Attached to the agent, not chained after it — a tool it may reach for

That third row is the structural idea of the whole lesson. A tool is not a step. It does not run in sequence; it runs if the agent decides to use it, and a run where it never did is a normal run. You saw this on the canvas in Answering questions on three channels — here it is what the build produces.

Checking it is a different job

You: Is it runnable?

"valid": true,
"runnable": true

Necessary, and nowhere near sufficient.

Runnable tells you it will execute. It tells you nothing about whether it behaves. A workflow you check by opening the canvas. An agent you check by reading its prompt out loud and then asking it the three questions you least want it to answer.

For a rules workflow you check	For an agent you check
That the arms go where you meant	That the Instructions say when to use each tool
That a threshold is on the right side	That the Constraints refuse what the business must refuse
That it validated	That it declines when the knowledge base has nothing

That the arms go where you meant

For an agent you check: That the Instructions say when to use each tool

That a threshold is on the right side

For an agent you check: That the Constraints refuse what the business must refuse

That it validated

For an agent you check: That it declines when the knowledge base has nothing

What to make it refuse, before anything else

The build above carried three refusals, and they were in the ask rather than added afterwards. That is the habit: an agent's limits are part of describing the job, not a review step at the end.

Never promise an outcome the business cannot promise — approval, an amount, a rate.
Never answer from general knowledge when the answer should come from the client's documents.
Say it is an assistant if asked. Every client will ask about this one.

Those three cover most of what a first-week compliance conversation is about, and they are three lines of English in a box the client's own team can open — which is the thing to show them, exactly as in Answering questions on three channels.

Change one thing — build one, then try to break it

Ask for an assistant that answers from your org's customer knowledge base and refuses to quote anything.
Check it is runnable. Then ignore that and read its prompt properly.
Ask it the three questions you would least want it to answer for a client.
Find the sentence responsible for each refusal. If you cannot find one, the refusal was luck.
Delete it. Do not leave an unactivated agent lying around in a demo org.

Try it

Build the same agent twice, once with a Constraints section and once without, and ask both the same awkward question.
Work out what happens if you point it at an internal playbook instead. Do not do it — say what a customer might be told.

Next: Building a dashboard by asking — the third kind of thing you can ask for, and the one clients ask for first.