Giving the Model Safe, Bounded Actions
Explore how to design AI action tools that perform safely by scoping capabilities narrowly and requiring user confirmation before execution. Understand the risks of action tools versus data tools, common engineering mistakes, and apply these principles to real-world AI features to keep them reliable and secure in production.
Two capabilities chapters ago, “please just refund me now” was diagnosed as needing an action, not more information. This lesson gives the model that action. Every tool this course has used so far, record_summary, record_grade, only returns structured data; nothing happens in the world if it’s wrong beyond a validation check catching it. A tool that issues a refund is a different category entirely, and it needs to be built like one.
In this lesson, we will cover:
Why an action tool carries different risk than a data tool, even though both use the same mechanism
Scoping an action tool as narrowly as the task actually requires
Requiring confirmation as a separate step from the action being proposed
How the same pattern shows up in a real product
The three ways engineers get this wrong
A quick check applying these ideas to a new scenario ... ...