Σ 0:00▸ 0:00

Module 3 · Agent Tools, Knowledge, Memory & Research Design · scripted

The Questions a Tool Can Ask

by Jules White

25 minoutcomes: tool-design, context-engineering
🎤 Talk view← Course

Overview

The language of action taught one law: what the language can't say, the agent can't do. This lesson is the other half of that law: what the language can't ask, the agent can't ground. The questions a tool set can express determine what the agent can know for certain — everything else it acts on is an assumption. So we design the questions deliberately, starting from the beliefs the agent will act on. And we go one step further: the language can be designed to require grounding — chaining tools so that certain actions cannot even be spoken until the check that justifies them has run.

Two things a tool set expresses

Read any tool set twice. Read it once for its verbs — what the agent can do. Then read it again for its questions — what the agent can ask the world.

Two readings of one tool set

verbswhat the agent can DO — schedule, send, write, book
questionswhat the agent can ASK — is the room free, what does the record actually say, does the total add up

The first reading bounds the agent's actions. The second bounds what the agent can ever know for certain.

The unaskable is the unknowable

Give an agent a verb without the matching question, and it can act but never know. Watch:

Example 1 · A verb with no question
user

You have the following tools available for use:

  1. schedule_meeting( people, time_range )

Task: Schedule the two-hour project review next week.

assistant
schedule_meeting(people = "project team", time_range = "Tuesday 2-4 PM")
user
Meeting scheduled.
✎ noteThe agent acted — but the language contains no question. Is anyone free on Tuesday? Is the room available? Nothing in this tool set can ask. Every booking rests on assumptions no call can test.
Example 2 · The same job, with questions in the language
user

You have the following tools available for use:

  1. check_calendars( people, time_range )
  2. check_room( room, time_range )
  3. schedule_meeting( people, room, time_range )

Task: Schedule the two-hour project review next week.

assistant
check_calendars(people = "project team", time_range = "next week")
user
All five free: Tuesday 2-4 PM, Wednesday 9-11 AM.
assistant
check_room(room = "project room", time_range = "Tuesday 2-4 PM")
user
Occupied. Wednesday 9-11 AM is free.
assistant
schedule_meeting(people = "project team", room = "project room",
                 time_range = "Wednesday 9-11 AM")
user
Meeting scheduled.
✎ noteSame verb at the end. The difference is what the agent knew when it spoke it. The questions in the language turned two assumptions into two observations.

A belief the language cannot ask about is a permanent assumption — and the miss is invisible, because nothing errors. The agent in Example 1 was not careless. Its language simply could not express the question.

Design from the beliefs, not the features

So there is a design method here, and it starts from the other end. Do not start from what the tool can do. Start from the beliefs the agent will act on — and design a question for each one.

The method

step 1list the beliefs the agent will act on — "the room is free", "the total is under budget", "this is the current policy", "the tests pass"
step 2for each belief, design the question that grounds it — a tool call whose answer confirms or contradicts it
step 3any belief left without a covering question is a place the agent will someday be confidently wrong

Designing tools around uncertainties

if the agent plans meetingsgive it ways to check availability, rooms, and conflicts
if it analyzes business performancegive it ways to inspect the underlying records
if it makes travel plansgive it ways to verify schedules, availability, and current conditions
if it creates budgetsgive it ways to calculate and validate totals
if it modifies softwaregive it ways to compile, run the tests, and examine dependencies

The language can require grounding

Everything so far makes grounding possible. The language can go further: it can make grounding required — by chaining the tools so that a consequential action cannot be spoken without the output of the check that justifies it.

Example 3 · The check the grammar demands
user

You have the following tools available for use:

  1. check_scheduling_validity( people, room, time_range ) — verifies calendars and the room; returns a signed validity id
  2. send_meeting_confirmation( details, validity_id ) — validity_id must come from check_scheduling_validity

Task: Confirm the project review for Wednesday 9-11 AM in the project room.

assistant
check_scheduling_validity(people = "project team",
                          room = "project room",
                          time_range = "Wednesday 9-11 AM")
user
Valid: all five free, room available. validity_id = "VLD-8842-a1"
assistant
send_meeting_confirmation(details = "Project review, Wednesday
9-11 AM, project room", validity_id = "VLD-8842-a1")
user
Confirmation sent.
✎ noteThe confirmation tool takes a parameter that only the checking tool can produce. There is no way to say "confirm" without having asked first — the check is not requested; it is required by the grammar.

Chaining forces checks

The consequential tool takes a parameter only the grounding tool can produce — a signed id, issued by the check.

No id, no action. The agent cannot skip the check, forget the check, or talk itself out of the check — the sentence cannot be formed without it.

The system prompt asks. The grammar requires.

This is the same move as the required rationale parameter from the planning lessons, aimed at evidence instead of thought: there, the grammar demanded a reason before acting; here, it demands a verification. And it is a cousin of making mistakes unspeakable — the unchecked action is not forbidden by a rule; it is unsayable in the language.

Promise certainty only where the language can ask

The coverage law said the language must be able to say a solution to every task you promise. Its epistemic twin:

The epistemic coverage law

If the task requires the agent to KNOW something — not assume it — the language must be able to ask the question that grounds it.

Promise certainty only where the language can ask.

And where certainty is impossible — where no tool can ask the question — the design answer comes from the safety lesson: that belief is exactly what should go to human review, or stay a draft until a person confirms it. The beliefs the language cannot ground are the ones the agent should not act on alone.