AI Governance · Evolved from Interface Contracts / API Productization
The Tool Contract
Treat every tool, connector, MCP server, and computer-use surface an agent can invoke as a product. Each gets a written contract: purpose, allowed actions, data scope, autonomy ceiling, eval cases, owner, and kill path. Autonomy without a tool contract is an undocumented integration.
Executive Guidance
How to hold this framework as a leader
The model is not the product surface. The tools are. Retrieval is a different product from an agent that can create tickets, move money, or operate a browser. The Tool Contract is the written product definition of each capability the agent may invoke.
Pair it with Agent Autonomy Tiers. The tier is the ceiling. The contract is the inventory. A T2 agent with an unsigned Salesforce write tool is not T2 in practice.
When to Apply
- Before wiring an agent to any internal system, SaaS connector, or MCP server
- When computer-use or browser agents can click, send, file, or pay
- When a tool catalog has grown faster than product ownership
AI-Era Notes
A tool grant is a product launch. Adding Slack send, Jira write, Salesforce update, or file-system access is a change of blast radius, not a config toggle. Re-attest the contract on any new tool, new scope, or new model that can call it.
Key Trade-off
Broader tool access increases usefulness and blast radius together; unsigned tools become shadow product.
Operating Sequence
The order in which to install the framework
- 01Inventory every tool, connector, MCP server, and computer-use action the agent can currently invoke.
- 02For each, write a one-page contract: purpose, allowed verbs, data classes, autonomy ceiling (T0–T3), reversibility, eval cases, named owner, kill path.
- 03Forbid tools that lack a product owner or a kill path. Default is deny.
- 04Bind the contract into the PRD + eval spec. A new tool is a new ship, not a hotfix.
- 05Re-attest the inventory when models, prompts, or connector scopes change.
Key Artifacts
The documents this framework produces
Tool Inventory
Complete list of invocable tools and owners.
Owner: Product + Security
Tool Contract
One page per tool: verbs, data, ceiling, eval, kill path.
Owner: Product
Grant Change Record
ADR-style log of tool additions and scope expansions.
Owner: Product + Engineering
Operating Checklist
What "good" looks like when installed
Inventory
- Every production tool is listed with a named owner.
- No shared human credentials are used as agent identity.
- Computer-use actions are enumerated as tools, not assumed away.
Contract
- Allowed verbs are explicit (read, write, send, pay, delete).
- Data classes the tool may access are named.
- Autonomy ceiling is ≤ the agent's declared tier.
- Reversibility of each tool action is classified.
Ship gate
- Eval cases exist for misuse, not just the happy path.
- Kill path is documented and tested.
- Grant changes are logged as product launches.
Common Antipatterns
- Granting tools because the demo looked better
- Shared admin credentials used as agent identity
- Tool lists maintained only in engineering config with no product owner
Boardroom Questions
- Can we name the owner of every tool our production agents can call?
- Which tools can send, write, file, or pay, and what is their autonomy ceiling?
- When did we last remove a tool rather than add one?
Pairs With