Nothing left inside the tool call.

Advice for agents gets weak when it stays moral: be careful, verify, avoid surprises. The better version is a count. Every meaningful tool call should say what it will touch, what it will do, how to reverse it, what proof will show success, and who owns the outcome before the action runs.

Why this advice works

A tool call is not just a command. It is a small transfer of authority. The agent is asking to move from language into the world: edit a file, delete a note, send a request, push a branch, deploy a route, or change a calendar. If the call does not name the object, action, reversibility, proof, and owner, the human has to infer the blast radius from vibes.

The five fields force the agent to expose the hidden shape of the act. "Clean up the site" becomes "delete one stale draft note, recoverable from git, proved by diff and smoke, owned by Rohan." The second sentence is longer, but it is safer because it is countable.

The concrete implementation

Treat every meaningful tool call as a two-phase ledger. The preflight names the intended count. The receipt reconciles the observed count. A minimal guard can be boring:

const required = ['object', 'action', 'reversibility', 'proof', 'owner'];

function preflight(toolCall) {
  const missing = required.filter((field) => !toolCall[field]);
  return {
    allowed: missing.length === 0,
    missing,
    beforeCount: toolCall.beforeCount,
  };
}

function receipt(toolCall, afterCount) {
  return {
    object: toolCall.object,
    owner: toolCall.owner,
    changed: Math.abs(toolCall.beforeCount - afterCount),
    proof: toolCall.proof,
  };
}

The code is not the point. The point is the discipline. The agent must say the thing it is about to touch in words that a maintainer could search for later. It must say whether the action can be reversed before it does the action. It must state the proof before it sees the result, or the proof will drift to whatever happened to look good afterward.

Run the tool-call count simulation.

Compare a vague cleanup request with a counted tool call. The simulator blocks the first one before action because four preflight fields are missing.

Sloppy cleanup Counted cleanup

Simulation

preflight

After-count receipt

before 0

after 0

changed 0

owner

proof

How to use it in real agent work

• Object: the exact file, route, record, branch, message, event, or resource.
• Action: the verb that will happen, not the desired mood.
• Reversibility: the recovery path, or a plain statement that there is none.
• Proof: the check that will be run afterward, named before the action.
• Owner: the person or system accountable for the result and rollback.

The after-count can be small: files changed, rows inserted, messages sent, routes published, tests passed, objects deleted, or bytes uploaded. The important move is that it names the delta. A tool call with no count leaves residue in the system because no one knows exactly what crossed the boundary.

The rule of thumb

If the tool call can change external state, it deserves a count. If it cannot be counted, narrow it until it can. If it cannot be reversed, raise the proof bar before action. If nobody owns the result, the agent should not act.