When the AI needs you, it asks a specific question

The pipeline runs on its own until it genuinely cannot. At that point it opens a typed request naming what is blocked and what answering will release, rather than sending you a notification.

Autonomy is easy until it needs something

A pipeline that sources, writes, sends, schedules and interviews on its own is straightforward to describe. The hard part is not the running. It is the moment the running has to stop, because the next step depends on something only a person can supply: a judgement about a brief, a ceiling nobody has authorised, a decision about whether this candidate goes forward.

That moment is not an edge case and it is not a failure. It arrives on every role, usually more than once. So the useful question about any autonomous system is not how much it can do unattended. It is what it does at the point it cannot.

A notification hands the work back

The usual answer is a notification. Something happened, here is a line about it, and the rest is yours. You open the role, reconstruct what state it is in, work out whether the event matters, decide what the response should be, and then go and do it somewhere else in the product.

That is a reasonable design for a tool and a poor one for something that claims to be doing the work. It gives you the easy part — the fact that an event occurred — and keeps none of the hard part, which is knowing what the event means and what would settle it. Twenty roles produce twenty of those, and the inbox becomes a list of things to think about rather than a list of things to answer.

An intervention has a kind

When the pipeline on EmployLabs needs a person, it does not post a message. It opens an intervention, and an intervention has a type. It is attached to the role and to the specific piece of work it is holding, and the type is drawn from a defined set rather than written out in prose each time.

Some of the kinds, each a different question:

• Low yield. The search is returning too little to be worth continuing in the shape it is currently in.
• Pool unclearable. What is in the pool cannot be worked through to a result as it stands.
• Needs ceiling. The work has reached a limit it is not permitted to raise on its own.
• No new supply. The market is not producing new people to consider for this brief.
• Budget exhausted. The spend allowed for this work has been used.
• Assessment approval. An interview is ready to go ahead and wants a person to say so.
• Approve an outreach send. A batch is ready to go to real people and wants a person to say so first.
• A reply that needs reading. A candidate has said something the pipeline will not act on by itself.
• Confirm a placement. A hire appears to have happened and needs confirming.
• Raise an invoice. The commercial step that follows a confirmed placement.

A notification tells you something happened. An intervention asks one answerable question and holds that work until you answer it.

What is blocked, and what answering it will do

Every intervention states two things: the work that is currently stopped, and what resolving it will release. That pairing is the whole point. It turns an item in a queue into a decision with a visible consequence, which is the difference between reading your inbox and working it.

It also makes the queue honest about priority. An intervention that unblocks an interview tomorrow and one that unblocks a line of paperwork are not the same urgency, and you can tell which is which without opening either. Nothing in the list is there to inform you. Everything in it is there because a specific piece of work is waiting on you.

Resolving one thing resolves exactly one thing

Answering an intervention unblocks what that intervention named, and nothing else. There is no blanket approval and no cascade where clearing one item quietly authorises three more you did not read.

This sounds like a restriction and is closer to the opposite. It is what lets you answer quickly. A decision whose consequences are bounded can be taken in a few seconds; a decision that might mean anything has to be investigated first, and the investigating is how an inbox stops being worked at all.

Supervising rather than monitoring

The practical effect is that your relationship with the pipeline changes shape. You are not watching it in case something goes wrong. You are answering the questions it has decided it cannot answer, in the order that matters, with the rest carrying on around you.

A role with no open intervention needs nothing from you, and that statement is worth as much as the questions are. It is only true because the system is willing to ask.

How to use it

1. Work the intervention list rather than the roles. It is already ordered by what is actually waiting, which a list of roles is not.
2. Read the kind before the detail. Each kind is a different question, and the kind usually tells you whether this is ten seconds or a conversation.
3. Treat a repeated kind on one role as information. A search that has twice reported it cannot clear its pool is telling you something about the brief, not about the pipeline.
4. Resolve rather than dismiss. The thing that was blocked stays blocked until the question is answered, which is the behaviour you want from anything holding real work.