What you need to know
Learn to separate model proposals from authorized actions, bind approvals to exact arguments and handle retries using a runnable in-memory tool example, solved exercises and a sandbox project.
An agent becomes consequential when a proposed action changes something outside the model. The important skill is not merely selecting a tool name. It is defining the action contract, enforcing permission, recognizing an uncertain result and recovering without repeating an unintended side effect. Begin in a sandbox where failures are safe and observable.
This guide uses an original in-memory record-closure tool. No real jobs are changed, no messages are sent and no model API is called. The example illustrates approval binding and repeated-operation handling, not a production transaction system or a complete security implementation. Google's function-calling reference provides background on model tool requests; application controls remain your responsibility.
Before you start
Understand dictionaries, exceptions and the difference between reading data and mutating state. Know why a request timeout does not establish whether a remote action succeeded. Use fictional records for the exercise; do not connect it to actual publishing, payments, email or account management while testing basic control flow.
A fixed workflow may be the correct starting design. If every task always follows the same validated steps, introducing an agent can add uncertainty without benefit. Choose autonomous tool selection only when you can explain what useful decision it makes and how that decision will be evaluated.
Learning sequence
- Define a narrow tool contract with explicit arguments, targets, permission requirements and outcomes.
- Separate a model's proposed action from the application's authorization decision. A tool suggestion is not permission.
- Bind human approval to the exact target, action and arguments, with appropriate validity and revocation rules.
- Save operation identity and state, then test repeat requests, conflicts and crashes around side effects.
- Add step and time budgets, cancellation and trajectory evaluation. Inspect what happened, not only the final message shown to the user.
Keep untrusted observations separate from control instructions. A website returned by a tool can contain malicious text; it cannot grant access to another record or authorize an additional action. A system prompt helps describe intent but cannot replace backend access enforcement.
Worked example
The action is a tuple containing the action name and target ID. The trusted caller supplies allowed target IDs and an approval matching that tuple. A completed operation is remembered under its operation ID. Reusing that ID with a different proposal is a conflict rather than an opportunity to execute again.