What I learned watching agents use my tools

A lot of the tools I use every day now get used more by agents than by me. There are CLIs I built for my own workflow, other people’s APIs, and a handful of MCPs. I’ve gotten better at building them by watching agents use them, the same way you’d watch people use a product. I notice where the agent gets stuck and change the tool so it doesn’t get stuck there next time.

I watch for repeated tool calls, or five calls to do something that should take one. I once watched an agent spend ten turns trying variations of a single flag. If I’m telling an agent the same thing twice, I usually need to change the tool.

Set the defaults for agents. Sesh, a CLI I built to keep track of what I’m working on, started with a --plain flag agents could pass to skip the colors and formatting meant for people. Almost all of its use turned out to be agents, so plain output became the default and the formatted version became the option.

Let them work the way they already work. Agents write longer content in files. When an agent created a new session in sesh, it would make an empty one, then open the file and fill it in. Now it can write the content to a file first and pass the path with --body-file, and sesh warns if the body is empty.

Don’t make them guess. After sesh created a session, it just said it was saved, so the agent would run another command to find out where the file was. Now it prints the full absolute path, because the agent might be in another directory or project. If a name matches two sessions, the error lists both and says to use the dated filename.

Don’t return a clean-looking lie. I have a CLI that manages the shared packages across my repos, and its doctor command checks whether everything is linked correctly. For a while it printed a green “Healthy” even when it had skipped the check that would have caught the problem. The agent believed it and moved on.

Test with a weaker model. Weaker models run into confusing parts of a tool that stronger models quietly work around. When I fix what trips up the weaker model, the stronger ones get better too. Smarter models make it tempting to skip fixes like these. I’d still make them.

When an agent doesn’t do what I want, changing the context I give it or the tools it uses usually helps more than changing the model. I’d check those first when building agent features into a product too.