Give the Agent Hands: Three Tools and One Permit
Explore how to equip an AI agent with three essential tools plus a permit function to control authority. Understand managing read, write, and command permissions to prevent unauthorized actions. Learn why limiting tools simplifies auditing and improves reliability, and see how denials provide clear, actionable feedback for ongoing verification.
Wren can hold a conversation and refuse a truncated batch. It cannot open a file, so every answer it gives about CLIN-547 is a guess dressed as a diagnosis.
This lesson fills the Execute seam. Three tools, one permit function in front of all of them, and 77 lines. agent.ts does not change by a single character, which is the first evidence that last lesson’s seam was real.
By the end, you run node run.ts and watch the agent read a real file, run an allowed command, and get refused when it tries to overwrite the source.
Which tools are worth having?
The ones a person uses in the first 10 minutes of debugging.
Read a file. Write a file. Run a command. Everything else in a mature harness is a specialization of those three: a patch tool is a careful write, a search tool is a command, and a test runner is a command with a parser attached.
Starting with three keeps the authority question in front of you. Each new tool is a new way for a session to reach outside its boundary, and the cost of that shows up in the permit function instead of in the tool.
There is a second reason to stop at three. A tool the model rarely picks is still a tool you have to reason about every time you audit the policy, and an unused capability is the one nobody remembers to check. Three tools produce a permit function short enough to read in one sitting, which is the only length at which anyone will actually reread it after a model change.
Where does authority actually live?
In one function that runs before any tool does.
Read it as a sequence of refusals, not a collection of tool implementations.
...