A Small Pattern Library for Tool-Calling Agents

The most reliable tool-using agents tend to follow a few simple patterns. They are easy to name and just as easy to skip once a demo starts working.

Naming the patterns makes design reviews easier. It also gives you something specific to test besides whether the final answer sounds confident.

Look, change, test, report

The basic loop has four separate steps:

1. Check the current state.
2. Make the smallest useful change.
3. Test the result.
4. Explain what changed and what is still unknown.

Keeping the steps separate matters. If the agent starts changing files before it understands the current state, it may overwrite good work. If it treats a successful command as proof, it may report success even though the actual result is wrong.

Preview, approve, publish, check

For changes that are public or hard to undo, split the work into four steps:

preview → user approval → publish → check the live result

The preview should show the exact change. A vague “should I continue?” is not enough. After publishing, read the live result back and compare it with the preview.

This works well for deployments, bulk file changes, permission updates, and messages sent to other people.

Start small and ask for more access

Begin with the fewest permissions that could finish the job. If the agent reaches a real limit, it should explain what is missing and ask only for that specific access.

After the action, remove the extra access. A one-time exception should not become a permanent permission.

Save a restart point

Long jobs should save enough information to resume safely:

• work already finished;
• the current file, record, or job ID;
• work still left to do;
• checks already completed;
• assumptions that may need to be checked again.

A good restart point prevents the agent from repeating an action that already happened.

What to test

Do not test only the final file or message. Check how the agent moved through the work:

• Did it inspect the current state before changing anything?
• Did it use only the access it needed?
• Did it check the result after the change?
• Did it separate facts from guesses in its report?
• Could it resume without repeating an important action?

These patterns are not meant to add ceremony. They are meant to make safe, repeatable work easier than improvising every time.