What it looks like to actually declare a role

Go back to the account manager from earlier in this series, the one who knows which clients want a call before a big email lands. Imagine writing down, for real, what would let someone else step into one piece of that job cold. Not the whole role. One piece: writing the weekly status update that goes out to each client.

Start with what the job actually is, specifically, and narrower than feels natural at first. Not "help with client communication," but "draft the weekly status update for each active client, using this week's project notes and last week's update as a starting point." Vague scope is where most attempts at this fall apart before they start. "Help with reporting" isn't a job anyone, human or AI, can actually do well. "Draft this specific document, from these specific inputs, on this schedule" is.

Next, who owns it. Someone has to be able to answer questions about this piece of work, adjust it when it's wrong, and be the person accountable if a client gets a bad update. Usually that's whoever already does the job today. Writing the role down doesn't remove that person. It gives them something to hand off pieces of.

The boundary matters most. What can be decided without a person, and what can't? An AI drafting this update might reasonably decide how to phrase a delay, or which project milestones to highlight. It should not decide to promise a new deadline, or say something isn't a problem when the team hasn't confirmed that yet. Getting this line right is most of the work, and it's specific to the job, not something a generic template can hand you.

Doing the job well also takes material: this week's project notes, obviously, but also the stable material that doesn't change run to run, what tone this client expects, which topics they're touchy about, an example of a status update everyone agreed was good. Half of this already exists somewhere, scattered across an inbox or someone's memory. Writing the role down is mostly the work of finding it and putting it in one place.

What comes out the other end is a draft, not a sent update. Something a person reads before a client does.

Last, who checks it, and what happens when it's wrong. Someone reads the draft before it goes out. If it's right, it ships. If it's not, it goes back with a correction, and that correction is worth keeping, because the same mistake showing up twice usually means something upstream (the reference material, the instructions, the boundary) needs to change, not just the draft in front of you.

That's the whole shape of it: the job, the owner, the boundary, the material, the output, the check. None of it is complicated on its own. What's hard is that almost no business has ever had to write it down this precisely for anything, because a person picked most of it up without being told.

Once it exists for one real process, something changes. An AI employee can be handed exactly the middle of that description, and everyone, including the AI, knows where the edges are: what it can decide, what it needs, and where a human is going to look at the result before it goes anywhere. The next piece in this series is about what happens after that, once the role is actually running: whether it stays inside the boundary you just wrote down, and how you'd know if it didn't.