Tool Registries and Receipts

Agents become useful when they can touch real systems: files, browsers, APIs, databases, calendars, queues, wallets, or deployment targets. That power is also where agent systems break. A tool registry makes capabilities explicit instead of letting every prompt invent its own authority.

In a governed harness, each tool should answer three questions:

• What can this tool do?
• Who or what is allowed to call it?
• What receipt proves what happened?

Receipts matter because an agent's final message is not enough. A final message says what the agent believes or wants you to believe. A receipt shows the run path: inputs, tool call metadata, outputs, errors, timestamps, policy decisions, and follow-up obligations.

The best harness engineers think about tools as contracts. A tool is not just a function. It is an ability with permissions, side effects, audit evidence, and failure modes.

When you build your proof packet, include a simple tool registry diagram. Show which tools are read-only, which can mutate state, which require review, and which receipts are saved. This makes your work much more serious than a screenshot of a chatbot.