LANDMARK · 7 MIN · BUILD
Tool contracts
After this landmark, you can write a tool definition that’s hard for a model to misuse; clear enough to call correctly, narrow enough to limit damage when it doesn’t.
You can still explore it. We’re showing the shared explanation and a related practical view without hiding the knowledge.
Giving a model a ‘tool’ (a function it can call, like send_email or delete_record) means writing a contract for a caller that doesn’t share your assumptions and can be manipulated by content it reads. A good tool contract has a narrow, specific purpose (not one do-everything function), a clear description the model can reason about correctly, and validation on the receiving end that doesn’t trust the model’s arguments blindly.
The tool’s name and description are part of the interface, vague ones lead to the model calling the wrong tool, or the right tool with wrong arguments, more often than you’d expect.
This is the canonical concept. It stays the same across learner lenses so personalization never changes the underlying facts.
What this looks like for you
Not your layer directly, but it’s why some AI assistants confidently do the wrong thing when given access to your calendar or email; the underlying tool contract let them.
MAKE A DECISION
You’re adding a tool that lets an agent update a customer’s account. What’s the safer contract?
CARRY THISList the tools one AI agent you use or build has access to. For each, write what the worst-case misuse looks like, and whether the scope is narrow enough to bound it.