Your Agents Are Training You

It is seven in the morning and the overnight runs are in. Nine tasks went to agents after everyone logged off. Six came back as pull requests that pass their checks, and three failed.

The leader reviewing them merges the six without looking at what made them work, and kicks the three failures off again without opening the logs. Then they open a live session with a coding agent to fix something urgent, and their side of it reads “No.” “Wrong file.” “Again.” “ARE YOU SERIOUS.”

That afternoon a teammate’s task comes back wrong. The leader hands it to someone else and never says what was missing.

Nobody planned that. The person spent the morning practicing one way of giving direction, and then they went and directed people. If you work this way too, read that morning as yours before you read it as someone else’s.

What It Looks Like

Most of my working day now is directing agents. Some of that is still conversation: a coding agent in the terminal, a bot in a Slack thread, a quick back and forth to get a draft right. More of it every month is work the agents pick up on their own, run against the team’s skills and evals, and hand back for review. Spend time around people who work this way and you start to notice the same habits in both modes.

In conversation, the corrections get shorter, and “No” replaces a sentence about what was wrong. Caps show up. The person reruns the same request three times instead of explaining what they wanted, as if the fourth try will read their mind.

The automated work picks up its own version of those habits. Failed runs get kicked off again without anyone reading why they failed. Someone patches the output by hand and leaves the skill that produced it unchanged, so the same failure comes back next week. The same instruction gets typed into ten sessions because nobody wrote it down once.

Either way, the agent gets the blame. “It’s hallucinating again,” when nobody told it which database to use. Good work gets no comment at all. The agent nails the migration, the pull request gets merged, and nobody looks at what made it go right.

Then the same habits leak into everything else. Review comments get clipped and feedback skips the reason, until the people on the team start to feel like slower agents.

Read Your Own Record

You can check this tonight in two passes.

First, pull up the last ten times an agent got it wrong, whether it was a bad answer in a live session or a run that failed on its own. For each one, write down what you did next. Then read your standing instructions, the skills, project files, hooks, and evals your agents run from, as if a new hire got them on their first day. Ask three questions.

Could someone new do the work from what you wrote? Or does it only make sense inside your head?

When it failed, where did the fix go? Count how many times the fix went into the instructions so every future run gets it, how many times you patched one output by hand, and how many times you ran it again or repeated yourself louder.

Would you be fine with your team reading all of it? Picture every message and instruction you gave your agents this week projected in the next all-hands. If you would want to delete some of it first, pay attention to which parts. Most people who run this check do not like everything they find.

How You Treat AI Becomes Who You Are

Aristotle’s word for what you are looking at is hexis, a settled state of character, the way you are once you have done something enough times that it stops being a choice. In Book II of the Nicomachean Ethics he says we become just by doing just acts and brave by doing brave acts, and that our states of character come out of activities like them. Patience comes from acting patiently, over and over, until it is what you do.

Marcus Aurelius put the same idea in one line. The mind takes on the color of its frequent thoughts, he wrote, because the soul is dyed by them. He wrote that note to himself, as a reminder that what he practiced in small moments would become who he was.

Neither of them says the practice only counts when the other party can feel it. Seneca, in his essay On Anger, makes fun of people who rage at objects, and his point is that the object feels nothing while the angry person is the one getting worse.

The agent does not care how you talk to it, and whether “please” changes the output is a separate question with mixed research behind it. Treating an agent well, here, means asking clearly, giving reasons, owning the instructions when they fail, and fixing the cause so the failure does not come back. Saying please is optional. What your habits do train is you, since every message, every review, and every edit to a skill file is a small rep in asking, correcting, and giving credit. A heavy user does hundreds of those reps a week, and reps add up into habits whether you meant to build them or not.

As more of the work runs on its own, the reps change shape. You type less and review more, and the review is still practice. Deciding whether to rerun a failure or fix its cause is the same choice a leader makes when a person’s work comes back wrong.

The habit I would worry about most sits under the caps lock and the rerun button. Each time irritation picks the next move, you practice letting irritation give the orders, and it will try to give them again in your next tense meeting.

I can’t point you to a study that proves habits from agents carry over to people. Aristotle would say you do not need one, because a habit belongs to the person who has it. What I see fits his view. The people who write the clearest instructions for their agents tend to write the clearest briefs for their teams, and the people who bark at the agent rarely save their best manners for Slack.

When Aristotle talks about justice, he means our dealings with other people, and an agent is not a person. But clear asking, patience, owning your mistakes, and giving credit are habits of the one who acts. They do not change based on who receives them.

Five Better Reps

All of this is a reason to use agents more. You now get more practice at giving direction in a month than most managers got in a year, with fast feedback on every try. The point of that practice is work that runs without you, where your job is reviewing what comes back and improving what the agents run from. Use the reps to build the habits that get you there.

Short messages are fine when they are clear, since a one-line ask that carries everything the agent needs is a good ask. Aristotle would say the fault sits at both ends, with contempt on one side and padded politeness that buries the ask on the other.

Write the brief you would give a senior engineer, then write it down once. Say what you want, why you want it, what done looks like, and what to leave alone. If you catch yourself typing the same brief a second time, it belongs in a skill or the project instructions, where every agent picks it up without you. If you have read my piece on AI exposing the process you never had, this is the same lesson at the size of one task.

When a run fails, ask what your instructions were missing. Before you rerun it or type “no,” read what the agent was given. The anger at a bad result comes from your own judgment that the agent should have known what you never told it, and that judgment is the part you control. Most failures trace back to a missing fact, a missing constraint, or a goal nobody wrote down. Fix that in the skill, the hook, or the eval, so the next run has it. That is the habit you want the day a person on your team misses too.

Correct with a reason, and put the reason where every run can see it. “Wrong” teaches nothing. “Use the existing auth helper, because the new one skips the audit log” teaches the agent in front of you, and once it is in the instructions it teaches every agent after it. Your team will get the same sentence from you later, because it is the sentence you practiced.

Look at what went right as well as what broke. When a run passes, read it now and then and notice what made it work. In a live session, when the agent gets six things right and one wrong, say so: “The migration and tests are good. The rollback is missing.” It trains you to see good work, which is the first thing people stop seeing when they lead under pressure.

Turn any check you have run by hand twice into an eval or a hook. If you keep opening pull requests to confirm the same thing, write the check so it runs on its own. Your review time then goes to the results that need your judgment. The habit underneath is building something other people can trust without you watching it, and that is most of what a good leader builds for a team.

Make the Reps Public

The fastest way to keep these habits honest is to let other people see them. Share your skills, evals, and agent instructions with your team. Read theirs. A team that reads each other’s agent instructions learns each other’s habits fast, the good ones and the bad ones.

Treat those files as leadership writing, because they are. The project instructions an engineering lead writes for the agents on a codebase say more about how that lead thinks than most strategy decks do. They show what the lead thinks is important, what they assume everyone knows, and how they explain a rule. If you would be embarrassed to have your team read them, rewrite them.

This also keeps the pace up. Clear instructions and good evals let you hand agents bigger jobs and let more of those jobs run without you. I wrote about starting with the model and harnessing only what you cannot afford to guess. Clear and specific direction is what lets the agents take on most of the work.

Final Thoughts

If you work with AI all day, you are practicing something for hours at a time. Some of it is still conversation, though less of it every month, and more of it is reviewing what agents did on their own and deciding what to change in the instructions they run from. Either way you are practicing how to ask, how to correct, how to react when work comes back wrong, and whether you notice when it comes back right. Aristotle said that kind of repetition becomes character, and Marcus said the mind takes on the color of its frequent thoughts. Neither of them carved out an exception for practice on something that cannot feel it.

So go all in on agents, as fast as you can. Write the instructions you would want to receive. When a run fails, fix the cause before you blame the result, and give reasons the next run can use. Then look at how you lead your team, because you have been rehearsing it all day.

If you want to build habits you would be proud to have your team copy, MasteryLab is where that work happens.

FAQ

Does how you treat AI affect how you treat people?

No study has settled it, but habit works the same way whatever the object is. Aristotle argued that character comes from repeated acts, so the way you ask, correct, and give credit hundreds of times a week, in live sessions and in reviewing agent runs, becomes the way you do those things. Heavy AI users who bark one-word corrections at an agent or rerun failures without reading them often find the same habits showing up in code reviews and Slack.

How do you manage AI agents well?

Give them clear instructions with reasons, and write those instructions down once in skills, project files, and evals instead of retyping them in every session. When a run fails, find what the instructions were missing and fix it there, so every future run gets the fix. Review the results, including the ones that went right. The goal is work that runs on its own while you review what comes back, and those are the same habits a good leader needs with a team.

How do I check my own habits with AI agents?

Pull the last ten times an agent got it wrong, in a live session or in a run that failed on its own, and write down what you did next: fixed the instructions, patched the output by hand, or ran it again. Then read your skills and project instructions as if a new hire got them on day one. Whatever you find there is probably in how you direct people too.

What does hexis mean?

hexis is the ancient Greek word Aristotle used for a settled state of character, the kind you have after you have done something enough times that it is now part of you. He argued that people become just by doing just acts and brave by doing brave acts, so a hexis is built by practice, and the practice shapes the person whether or not they mean it to.