Build the tool and approval matrix
You will be able to set least-privilege tool access, approval boundaries, and a handoff that lets a person continue without repeating the customer’s story.
Good agent work is useful before it is impressive.
Most avoidable agent failures come from too much authority, not too little intelligence. The first safe version often reads information, drafts a recommendation, and asks a human to approve the consequential action.
Move from read to recommendation, approval, and action
The language that keeps the work clear.
How to build the tool and approval matrix
List every tool
Write each lookup, write, send, schedule, payment, or deletion capability separately.
Rank consequences
Mark which actions are informational, reversible, customer-facing, financial, sensitive, or irreversible.
Set the first boundary
Start with read-only or recommend-only when uncertainty or impact is high.
Build the packet
Require the agent to preserve the facts, reason, customer request, and recommended next step for the human owner.
Worked case: design tools, approvals, and handoffs
An agency builds an appointment assistant for a contractor. It can read service areas, appointment availability, and a lead’s stated needs. It can recommend a slot and create a draft booking record.
It cannot cancel an existing appointment, promise a price, or message a customer outside approved templates without an owner’s approval. If the lead describes a safety risk, it creates an urgent task and uses the approved emergency-routing message.
The dispatcher receives the full handoff packet, not a vague notification that says ‘AI needs help.’
Complete the working artifact
Tool calling is an authorization boundary.
A valid function name and JSON shape do not make an action safe. The application must validate arguments, authenticate the acting identity, authorize the specific resource, limit the operation, and return an explicit result the agent can interpret.
- Use typed inputs and reject unknown fields.
- Make write operations idempotent where possible.
- Require approval for actions whose cost or consequence cannot be reversed easily.
- Log the request, identity, decision, result, and error without exposing secrets.
Sources used for this check
Before you move on
- Inventory the proposed agent’s tools.
- Downgrade one risky action to recommendation or approval.
- Review whether the human can reconstruct what happened from the handoff packet.
- Every tool has a job-specific purpose.
- High-impact actions have approval or are removed.
- The handoff contains evidence and a next step.
- The first release is more limited than the eventual ambition.
Failure drill
A harmless tool call becomes a customer-facing mistake
The case
An agent may draft a refund, issue it, and email the customer through three tools. The same instruction covers all three actions, and the approval screen shows only a generic 'continue' button.
Your call
- Which actions need separate authority?
- What must the approver see before acting?
- How will the system prevent the same action from running twice?
Reveal a defensible response
Response: Separate drafting, approval, execution, and notification. Show the customer, amount, reason, policy source, and exact action at approval time. Give the write operation a narrow permission and an idempotency key; log who approved it and what happened.
Lesson progress
Finished this lesson?
Save your place on this device so it is easy to pick up where you left off.
Not marked complete yet.