The skill gap blocking a task is usually about twenty minutes wide

The most expensive sentence in a small company is some version of this:

"She would be perfect for this, if only she knew how to set up the project."

I have watched this block real work more times than I can count. An office manager who had the context and the patience to reproduce a nasty intermittent bug - but not the local toolchain to reach it. An artist whose eye was exactly what a feature needed - who could not run npm install against a private registry. A teammate who could tell you in ten seconds whether a workflow made sense, but who had never written a prompt that a coding agent could act on.

None of that is a story about talent. It is a story about where the gap sits.

The gap is at the entrance, so the whole task waits

Here is the structural problem. The missing knowledge is usually small - twenty minutes of tooling trivia. Which command starts the app. Where the staging test account lives. What a good delivery report looks like.

But that small gap sits at the entrance to the task. And a gap at the entrance doesn't cost you twenty minutes; it costs you the entire task, because the task now has to wait for one of the three people who can cross the threshold unaided. Those three people are, of course, the people who are already the bottleneck for everything else.

So the work queues behind them. Not because it is hard. Because it is unenterable.

"Can this person do engineering?" is the wrong question

We ask it constantly, and it's malformed. "Engineering" isn't one act. Shipping a change involves at least: understanding a requirement, locating the relevant code, changing it, running it, noticing a visual defect, checking permissions, testing an edge case, and deciding whether the result is acceptable.

Those are genuinely different skills, and almost nobody is uniformly strong across all of them.

• A teammate unqualified to design an authorization system may still be the best person on the team at noticing that a customer flow feels broken.
• An artist who doesn't know your build tool is very likely your strongest judge of whether a transition regressed.
• An ops teammate who will never write the fix often knows the only reliable sequence that reproduces the bug.

Once you stop treating "engineering" as a single competency, a task stops being all-or-nothing and starts being decomposable.

Decompose the task into four parts, not two

The instinct is to split work into "the technical part" and "the rest." That's too coarse. In practice a bounded task becomes transferable when you separate four distinct things:

1. The domain brief. Somebody who actually understands the problem writes down the outcome, the constraints, and the boundaries. What "done" means. What is explicitly out of scope.

2. The agent guidance. The coding agent gets technical context, setup instructions, the work request, and - critically - stop conditions. When should it refuse to continue and ask?

3. The human runbook. The person running the task gets a short, concrete list: which access to use, what to observe, what judgment only they can supply, what to QA, and when to escalate.

4. The acceptance step. Evidence goes back to a qualified reviewer who decides whether the thing is actually complete. This is a separate decision from "the work was performed."

domain expert's brief + technical context
                |
                v
   human runner  <-->  coding agent
   access, eyes         setup, implementation,
   judgment             explanation
                |
                v
     evidence + recorded delivery
                |
                v
     qualified review and acceptance

Notice what this is not. It is not "give the task to somebody cheaper and hope the model covers the difference." The expert's knowledge stays in the system in two places: once in the brief, and again at review. The runner's role is real rather than ceremonial, because the task explicitly names a check they are equipped to perform.

The research warning is also the argument

The strongest caution about this idea is also the clearest case for it.

In a preregistered experiment, BCG gave consultants access to and training on GPT-4 for tasks outside their existing skill sets. On tasks that sat inside the model's competence, assisted consultants performed substantially better than unassisted ones. On tasks positioned just outside it - where the model was confidently wrong - assisted consultants did worse, because they accepted plausible output they lacked the expertise to challenge.

Read that carefully, because both halves matter:

• Capability genuinely transfers. A non-specialist with a good agent and a good brief can complete real work.
• Capability transfers only up to the boundary of verification. The moment nobody in the loop can tell good output from confidently wrong output, you have not distributed the work. You have distributed the risk.

That is exactly why the fourth part - acceptance by a qualified reviewer - isn't bureaucratic overhead. It's the thing that makes the other three safe. Assisted performance is not the same as expertise, and a handoff design that forgets this converts a skill gap into a silent defect.

What this means practically

If you want a task to be transferable, the work is mostly front-loaded and mostly writing:

• Write the brief before you offer the task, not after someone claims it.
• Give the agent and the human different instructions. One generic paragraph asks both of them to improvise.
• Name the specific human check the runner is qualified to perform. If you can't name one, the task probably shouldn't be handed off.
• Keep delivery and acceptance as two separate events. "The runner reported it" and "the reviewer accepted it" are different facts.
• Be honest about the verification boundary. Some work should not be handed off at all, and a better prompt cannot repair a missing qualified reviewer.

The payoff isn't that job titles stop mattering. It's that a narrow twenty-minute gap stops being able to hold an entire task hostage.

---

I work on Wagglet, which is built around this pattern - an author prepares a task for two audiences, a teammate claims and runs it on their own agent subscription, and acceptance stays a separate decision. If you want the longer version of the argument above, it's written up as a field note: How AI task handoffs help more teammates complete technical work. The five-stage lifecycle is documented at how it works.

How does your team handle this? I'm curious whether anyone has found a good way to decide in advance which tasks are safe to hand off.