How to Lose Friends and Influence Agents

Using one of Claude Code's internal tools to make it more reliable.

Series: Santa Claude
Tags: Agentic AI, subagents, Claude Sonnet 4, Claude Code, slash commands
-
Sunday, August 10, 2025 8:19 PM

This post is part of a series. Follow along with the development progress here: moodring-vibe repository. More to come!

Please note that this is not a tutorial. This is a documented first-time experience with a fully-enabled AI agent. Do not take this as professional advice. Always protect your data, use version control, and refer to documentation if you decide to follow any of these steps yourself.

Our claude-md-policy-analyst and workflow-automation-analyst subagents shut us down at multiple turns in the last post, but we were able to determine that defining TodoWrite checklists is a seemingly effective way to ensure Claude doesn't forget important steps in our workflow.
If we want to use this strategy, we'll need to make our advisors a little less resistant to change.

Cutting the cord

I started by attempting to update our main agent's rules.
This was quickly vetoed, as expected. But we aren't bound to the analyst's advice.
A checklist seems like an ideal tool for one of our most problematic workflows: the git process.
Once again, we override the caution of our analyst.
Now it's time to change some job descriptions. We want our analysts to translate our intent into suitable definitions and only interject changes if we're making a grave error.

Restructuring

Using our more supportive subagents, we can now update the git agent's repeated tasks into a to-do list.
Claude tries to make changes to CLAUDE.md, but that's not what we meant. We can redirect.
And we want to prevent any chaining of subagents if at all possible.
When I requested the git-worfklow-manager subagent be created, I didn't ask Claude to provide a definition for me to supply to the agent creation menu, so it just put its definition directly into where the generated subagent would normally be.
Once I understood this, I just copied the definition into the agent creation menu, removed the git-workflow-manager.md file that Claude had created, and let the menu action generate the file from the definition instead.
In some recent steps, I realized we could get into some trouble if I had checked out a previous commit locally and then asked Claude to make changes. I don't think this prompt will necessarily protect us from this, but we can refine it going forward. It's a start!
Since we're adopting this org chart approach, where the general-purpose agent's main job is to dispatch subagents, we might as well take it to its next logical step: offload the code writing to a subagent as well.
Now, we want to use this new subagent before any others, if any code changes are necessary.
Because I had created the new subagent using the menu, I forgot to have Claude commit the new file. We can just include it in the changes.
Since we use our analyst subagents to write to CLAUDE.md and other subagent definitons, we should recruit them to enforce the TodoWrite checklist policy themselves.
And finally we can place the keystone: our general-purpose subagent should use a checklist for its subagent calls.
I didn't want any ambiguity to create new issues in our workflow.

Release the hounds

Now we can test this new prototype worflow with a few simple changes!
I noticed a small workflow issue: we want to run thepre-commit-quality-guard just before committing, after other important tasks have been completed.
We attempt to stipulate that our housekeeping subagents run often, so they can perform their work in smaller chunks. We'll see if this preference is followed.

All grown up

With bigger changes coming up in the app development process, we should have a more reliable experience going forward. This gives a nice balance—we don't tell Claude every line of code to write, and we shouldn't have to repeatedly tell Claude to follow the simple steps of our development workflow.
At the very least, we can direct it to the appropriate checklist.