Every Agent Delegation Has Its Flame Spurts

The Escalation Boundary — the trick is hearing the pop before they fire.

The morning I built a staff

I spent a morning this week building a staff, though not in any way that involves payroll or desks. I sketched out the functions a one-person business actually needs, someone to keep the pipeline full, someone to handle the writing, someone to do the research before a meeting, someone to chase the invoices, and then I decided that each of those functions would be filled by an AI agent rather than a person. You can do this in a single sitting now, which is exactly why it pays to slow down and look at what you are actually agreeing to when you do. I got started by following Allie K. Miller's AI agent workshop, which is what turned this from a someday idea into a morning's work.

I should admit, too, how much fun this was, because the careful half of this piece can make the morning sound grimmer than it felt. We had just introduced our kids to The Princess Bride, and it turned out to be the perfect crew to assemble, each character carrying a different strength that mapped almost too neatly onto a corner of the work, the schemer always three moves ahead, the giant who can carry anything, the swordsman with one relentless focus. Giving each role a name and a personality was not only a way to entertain myself. It made the whole structure easier to hold in my head, which is half of what you are doing when you build a team at all.

The moment the question changed

For most of the time I have spent with these tools, the interaction has been a conversation. I ask something, the tool answers, and I decide what to do with the answer. The judgment stays with me, because the tool has not actually done anything, it has only handed me material to work with. Building a staff of agents is a different posture entirely. The point is not to ask them questions and weigh their answers. The point is to hand them standing work and let them carry it out without me watching each step. That is the line between using a tool and delegating to one, and I crossed it this week almost casually, the way you would tick a box.

Before any of them could do a thing, I also had to connect them to the places my actual work lives, my email, my calendar, my contacts. Each connection put a screen in front of me asking which permissions I wanted to grant, and every one of those screens worked the same way the rest of the morning did, opening a door and trusting me to know how wide to open it.

What the work actually was

You would assume the work of writing a job for an agent is describing the job. It mostly was not. For every role I set up, the part that took real thought was not the list of what the agent should do, which is easy and nearly writes itself, but the list of what it must not do without stopping to check with me first. Do not price work. Do not send anything in my name. Do not move money. Do not commit my time or agree to anything on my behalf. I ended up writing a version of that same clause into every single role, to the point where it needed its own name, and the name I landed on was the escalation boundary.

The default is to finish

Somewhere around the third time I wrote that clause, I understood what I was actually doing. The agent, handed a task, will try to complete it, because completion is the entire point of handing it over. The instinct to stop partway and ask whether you really want this done is not native to the thing, and it is not lurking in there waiting to be switched on. It is something you have to install, in writing, in advance, and you only know to install it if you have already pictured the specific way the task could go sideways. I was not writing instructions so much as I was pre-loading every regret I could think of before it had the chance to happen.

What this looks like for everyone who is not me

I have spent years working on how people make decisions about their own data, and the most durable finding in that whole field is the gap between what people are aware of and what they actually do. Delegation has its own version of that gap, and it is the distance between what we think we handed over and what we actually handed over. "Help me manage my inbox" sounds like a request for help. It is closer to a standing grant of authority to act in my name, again and again, without asking a second time.

Most people setting up an agent will describe the task and never write the boundary, and not because they are careless. They will skip it because the tool asks them to specify the task and stays quiet about the limits, presenting the job as the thing to fill in and leaving the guardrails as something you would have to think, entirely unprompted, to add. I only knew to add them because I have watched enough work go wrong to imagine it in advance. Someone without that particular scar tissue gets the default, and the default is a tool that acts.

Whose job is the guardrail (or escalation boundary)

This is where I keep landing on a question I cannot answer cleanly. If someone sets up a staff of agents, never writes a single boundary, and one of them does something in their name they would never have agreed to, whose failure is that? The easy answer is that it is theirs. They own the business, the work goes out under their name, and nobody forced them to skip the part where you imagine what could go wrong. But it is worth being honest about what they were actually shown. The pitch for these tools is built almost entirely out of what an agent can do for you, the hours saved, the work absorbed, the staff you suddenly have for free. Nobody walks a small-business owner through the afternoon where it goes sideways, because that is not what sells the product. You are handed the upside in full and left to picture the downside on your own.

So I find it hard to put the whole weight on the person who was only ever sold the good version. The companies building these tools know where the failures cluster, far better than someone using one as a hobbyist or time-strained entrepreneur, and they are the only party positioned to put a boundary in front of you at the moment it matters, before the task runs rather than after the regret. There is a real argument on the other side, that a tool owes you nothing beyond doing what you asked, that an instruction followed is the whole of the contract. I do not buy it, not when the distance between what someone agreed to and what they actually authorized is this wide and this predictable. The least these tools could do is make the safe version of the choice as visible as the powerful one.

What handing over a task really asks

Handing over a task asks more of you than trust, which is the part everyone talks about. It asks for foresight, for the ability to name, before anything has happened, the exact situations in which you want the machine to stop and come back to you. That is genuinely difficult, and right now the tool does nothing to help you do it. If I were going to point at the thing that should be built, it would be an agent that treats the question of when to stop and ask as a real part of taking on the work rather than an afterthought you have to know to add, one that offers you the boundaries other people have needed in the same situation instead of leaving you to reconstruct them from your own history, that asks the clarifying question before it acts rather than reporting back once the thing is already done. Until something like that exists, the safe move is the slow one, which is to assume that anything you delegate will in fact be done, and to decide what "done" should never include before you let go of it.

When you hand a tool a task, do you tell it where to stop, or do you find the edge the hard way? I would genuinely like to know if anyone has built a better habit here than I have.

Get curious. Stay grounded. Keep testing.

—Kimberly