In short: Role two doesn't follow the same four criteria as role one. What matters now are two new facts: what your first review reveals about your own checking, and how clearly the handoff between both roles is defined through Domains and Routines.

Your Second Role

Role one, your first AI operator routine, is running. Role two, the next one, gets picked on different grounds, and that's not a downgrade.

Role one has been running for a few weeks. The operator is configured, FTT (First Time Through) gets checked weekly, and the role may already have moved up a level on the Adoption Levels. The next thought arrives almost on its own: if that worked, do it again. Find another task where "done" is describable, that repeats, where a mistake is cheap, and where access stays narrow. Set up the next operator on the same template. Start this one on Shadow too.

That instinct makes sense. It's also the wrong lever for this step.

The four criteria for the first role answer a question role two has already settled: whether you can define a standard at all and check work against it. That was the real risk in role one, not the task itself. Role one carried that risk so you could learn the mechanism without an expensive mistake along the way. You have that mechanism now. What's still open are two other things, and only role one could teach them to you, because there was no second role for them to show up against before.

What role one actually revealed about your own checking

The first is the state of your own review, not the operator's abilities. Across the weeks in the weekly review, a pattern sorted itself into two groups.

One group held up reliably: a fixed length, a format, a specific number, a match against a template. There, "done" was already translated into something checkable before the work even started, and the check itself takes seconds, because it needs no judgment call, only a comparison.

The other group kept slipping: tone, prioritization, "this feels right." That's where something usually got through, because the standard behind it never became fully explicit. It lived in your head, never written down anywhere, and you only notice that the first time you wave something through under time pressure instead of actually checking it.

Role one didn't reveal what the operator can do. It revealed where your own checking is already a standard, and where it's still a gut call.

This split isn't a verdict on you. It's a map, and it marks a domain, not a general skill. You might check numbers precisely and prose loosely, or the other way round. That map, not the four old criteria, is what should help decide where role two belongs.

The interface becomes real

There's a second thing role one couldn't show as long as it stood alone. In the Tools tab, every operator has a field called Routines: "Routines, or whole domains, this operator is allowed to touch. This is the ONLY control that grants routine access, nothing else in the product currently does." That's not a side note, it's a real boundary. Nothing else in the product currently decides who may touch which routine.

With a single role, that grant is whatever the role needs, and nothing else interacts with it. There's no second domain assignment for its access to collide with, so a badly scoped or vague handoff never gets tested. The common mistake is designing the role in isolation, and with a single role that mistake stays invisible. A person on the other end of a handoff fills the gap automatically, without anyone noticing there was a gap.

The moment a second role exists, its Routines and Domains grants sit right next to the first role's, alongside its own Tools and Connections. That's exactly where an undefined handoff, what counts as "done" from role one, in what form, checked by whom, turns into either a real blocker or a handoff that quietly goes stale without anyone noticing.

One illustrative example, not a claim about any real role: a content role's Domains cover content, its Routines cover drafting and approval. A distribution role has its own Domains and Routines for the channels drafts go out through. Both sets of access look clean on their own. The trouble surfaces only once "approved" was never defined as an actual output of the content role, because "done" so far just meant a person read it. That's not enough for role two. It needs a state it can recognize reliably, not a feeling. Without that definition, role two either starts on a stale version, or it waits on a signal role one never sends.

The same gap also decides what happens when role two depends on something role one hasn't finished yet. Without an explicit answer, role two either blocks quietly, or worse, it works with whatever happens to be there, and nobody notices until the output is already out the door.

How to actually pick role two

The four criteria from last week, describable "done," weekly repetition, cheap mistakes, narrow access, don't carry over to role two unchanged. They existed to make the first bet safe while you learned the mechanism. That bet is settled. Role two doesn't need proof that you can write a standard. It needs an answer to a different question: in which domain is that standard already strongest in you, and where does that domain actually touch role one's work.

Go back to your review notes and sort where checks caught real problems reliably, and early, not just at the end. Not the domain that's most tempting because it looks new and interesting. Not the domain that's most painful because it's been grating for months. That's the same pain-driven pick the first selection already ruled out, now with a badly defined interface stacked on top. Choose the domain where you can say plainly when an output fails, and where a handoff to another role can be described cleanly.

Company 0

For us this shows up at the handoff between the role that writes and publishes the article and the role that writes the social posts around it. The second one needs the article's live address to put in the Tuesday post. That handoff was never defined as a signal, it has always run on a convention: the social role checks the address, and if the page isn't there yet, it leaves the link out.

In practice that means the link gets added after the fact almost every week, once the article is live, because both roles work close together in time and the second one finishes before the first has published. It works, but only because someone closes the gap by hand every week. That is exactly what this article describes: an interface that stays invisible for as long as a person quietly fills it in.

What this means for you

Before you settle on role two, write down one thing: where does role one's output land right now, and who or what touches it next. A person, a system, a folder, a customer. That answer isn't busywork. It's the interface role two has to respect, before you even know what role two is called.

If you find you can't answer that cleanly, that's not a setback. It's the same kind of finding as with role one: a spot where something has only ever existed in your head, this time not the standard for an output, but the path it takes afterward.

Frequently Asked Questions

When am I ready for a second role?

When your first role's FTT is stable and your weekly review shows you which domain your own checking is already reliable in. That map of your checking, not whether the first role "worked", is what decides.

Do I need to apply the same four criteria again?

No. The four criteria secured the first bet while you learned the mechanics. Role two runs on a different question: which domain is your checking already strongest in, and where does that domain touch the work of role one.

What is a Routines grant, and why does it only matter once a second role exists?

In the Tools tab, the Routines field sets which domains an operator may touch, the only control in the product that does that. With a single role nothing overlaps, so a vague handoff stays invisible until a second role shows up.

What should I actually do before I pick role two?

Write down where role one's output lands today and who or what picks it up next, a person, a system, a record. That one answer is the interface role two has to respect, before you even know what role two will be.