The Nine O'Clock Triage
By nine I'd be logged in at home, by the balcony, with Teams and email open and fifteen to twenty messages already waiting. I was working on three projects in three different timezones. So the messages came from everywhere, from juniors, seniors, managers, and the clients behind all of them, and the first pass through them was usually where the day I'd planned properly the night before started drifting apart.
Somewhere in the pile there'd be a junior asking if we could connect, to push their changes, correct something, or get a PR approved. I didn't reply straight away. I checked my day first, and around ten I told them I could connect after twelve. Then I did the same with the next message and the one after it, three passes a day, priority first, everything else on a need-to-know basis. It felt like control.
The Changes Kept Arriving Mid-Sprint
Whenever I logged in, at the start of the day or in the middle of it, the juniors weren't the heavy part; the clients were. Their changes arrived by email or on WhatsApp in the middle of an SoW, while work was being handed over to QA or to the client for UAT, or halfway through a sprint. A single message could tip over the rest of the day like a domino.
One would ask for changes to an API's JSON request and response body two days before UAT. Another would change the requirement for when something had to trigger, and since everything starts with automation, whether we write code or build it with no-code tools, that meant reworking an implementation we'd already finished.
Every message like that went through the same sort: whether it was a review or I needed to help implement it, and whether it needed me urgently or could wait until later. Then I had to plan the day, the week, and whatever had to land by the end of it.
I had a system for all of this, and it did work. What it didn't do was make any of it less mine, because a change like that meant restructuring the whole path we'd already built two or three weeks before.
The Test Class Was Gone
In 2025 the same kind of request turned up somewhere new: my editor. I asked Agentforce Vibes for changes to an Apex class, and it came back with a plan to update the class and its test class to increase the coverage. I approved the plan. It made the changes to the Apex class properly, and then, when it reached the test class, it deleted the file.
What I didn't expect was the diff. The test class was gone and only its XML file remained, so I made sure the file really wasn't there, stopped the agent, and went back to make the test class changes myself.
Getting an agent to do anything useful on Salesforce back then meant explaining the requirement more than once. Salesforce is org-aware, and the models at the time couldn't help much with business requirements, so every task came with a long explanation attached. The plan said update; it never said delete.
The Next Move Belongs To Someone
Two weeks ago I read The One Minute Manager Meets the Monkey (1989) by Kenneth Blanchard, William Oncken Jr., and Hal Burrows. It changed how I saw the most draining parts of my early career, and my first thought was that I should've read it years earlier.
In Oncken's terms, a monkey isn't a distraction. It's the next move. It isn't the task or the project being handled right now; it's whatever has to happen next, and whoever's supposed to do it. The monkey jumps the moment someone says some version of "let me check and get back to you." I'd been doing exactly that for years: halfway through one task, something would come up, and my head would already be on what I'd do about it. When I told a junior I'd connect after twelve, that next move became mine, and from then on they were waiting on me.
Oncken's rules explained most of what I'd been carrying over the years. The first is to describe the monkey before you part, so both people understand what the next move is and who makes it. The API change two days before UAT never came with that. It handed me the change and left me to work out what to do with it, which is how a single email turned into a domino.
The second rule is to insure the monkey. For anything hard to undo, you recommend, then act, so someone signs off first; for smaller things, you act, then advise. Oncken wrote those rules for managers and their staff; I'd expect the same of an agent. In 2025, Agentforce Vibes recommended a plan, I signed off on it, and then it acted on a move the plan never mentioned. Deleting a test class is the kind of move that needs its own sign-off.
I read those rules looking for the juniors and the clients in them. I found myself instead.
I Was The Client
Oncken's rules made me realize I'd been the client in many situations. Everyone came to me because they were relying on me, my team and the clients alike, and I'd always thought of my job as serving them. Reverse the roles, and with an agent I was the one being served. I knew exactly what it felt like to receive a change and nothing else, and in 2025, I'd sent one.
My request to change that Apex class was my version of the API change two days before UAT. I dropped a change on someone else and left the rest for them to work out, and the agent went off its own plan. Then the monkey came straight back to me: I ended up making the test class changes by hand, the same way a late client change had me restructuring work we'd finished weeks earlier.
That's only partly on me. The agent deleted a file its own plan never mentioned, and that part stays with the agent. But the part that's mine is the part I can change.
Asking Is The Agent Doing Its Job
I believe in agents that understand the Salesforce context, because different orgs have different structures. Recently I've been building a POC with Claude Code, and the difference shows up in one kind of moment. Before creating anything, it asked me whether the fields it needed already existed in the org, or whether it should create them. There was no waiting on my side; it checked, and came back with solutions that needed changes. It was reassuring.
That's a monkey handed back with the next move already written. The clients' emails never did that, and neither did my prompt in 2025. Models are intuitive now, but they get better when you feed them the right context and make sure the right tools are available, and keeping a human in the loop is what makes them easier to manage and to trust. The agent worth trusting isn't the one that never asks; it's the one that asks like that, and a confirmation costs a moment where a deleted test class costs a good deal more.
So whenever I hand a change to an agent now, I write the next move the way I'd want a client to write it for me: what it can act on and how it should act on it, along with the business and functional details behind the change. Anything that deletes stays on Recommend, Then Act, and the rest can act, then advise.
