Grounding: Asking the World If You're Right

Overview

Tools are not only ways for an agent to do things. They can also let an agent find out whether something it currently believes is actually true. In this lesson we name these grounding actions, watch an agent test a proposal against the world and revise it, learn to ground not just the action but the relationships around it, and see how this changes the way we design toolsets.

Tools can test beliefs, not just do things

A tool call does not have to change anything. It can be chosen purely to find out whether the agent is right. A grounding action is an action chosen to determine whether something the agent currently believes is actually true — an interpretation, an assumption, a prediction, or a proposed solution.

Suppose an agent concludes that the 2:15 PM train will get us to the airport in time. Rather than simply continuing to reason from that assumption, it can check the live train schedule and the flight departure time. Suppose it concludes that sales declined because we lost several large customers. It can query the underlying sales records and test whether the decline is actually concentrated among large customers. Suppose it proposes moving the workshop to Thursday because everyone appears to be available. It can check the participants' calendars. In each case, the tool connects the agent's reasoning to evidence outside of its own generated reasoning.

A belief, a check, an update

Grounding does not mean confirming — often the most valuable observation is the one that shows the agent was wrong. The important capability is that the agent can take actions specifically designed to test its own beliefs. Watch that happen:

The agent could have scheduled the meeting immediately. Instead it checked first, learned it was wrong, revised, and checked again.

What grounds what

Different beliefs call for different checks. The pattern is the same every time: name the belief, then find the action that tests it.

For every belief the agent is about to act on, there is usually a tool call that could test it. The design question is whether the agent has that tool and thinks to use it.

Grounding a proposed solution

A finished proposal is still a belief. Before presenting it, the agent can test it. Suppose the task is a catering plan for 30 people with a budget of $1,000, and the agent builds a menu it believes totals $940:

Grounding also catches a subtler failure: information that is true but not enough. Suppose the agent must recommend a room for a 60-person workshop. It finds a room described as "Capacity: 75." That seems sufficient. But a grounding action reveals that 75 is the capacity for theater seating — with tables, the room holds 42.

Ground the relationships, not just the action

Often the most important errors are not contained in the proposed solution itself. Suppose an agent is asked to move the department meeting to Thursday. The agent successfully finds an open time. But the room may already be occupied. A key participant may be traveling. The meeting may need to happen before Friday's board meeting. Catering may already have been ordered for Wednesday. The time was right; the world around the time was not checked.

Tools have a second job

It is tempting to describe tools only as capabilities. A calendar tool lets the agent schedule meetings. A database tool lets the agent query records. But there is another design question: what uncertainties should this agent be able to reduce?

Designing the questions a tool set can ask — and making some checks required, not optional — gets a lesson of its own next.

The whole picture

Grounding completes the loop this module has been building. The agent interprets the task, acquires the information it needs, reasons over it, proposes an answer — and then asks the world whether the proposal holds, observes what comes back, and revises.