How AI task handoffs help more teammates complete technical work

One of the most expensive sentences in a small company is:

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

The missing piece may be twenty minutes of tooling knowledge. It may be knowing which command starts the app, where the test account lives, or what a good delivery report looks like. But because that narrow gap sits at the entrance to the task, the whole task waits for one of the few people who can cross it unaided.

I have seen this repeatedly in my own company. An office manager had the care and context to reproduce a small product bug, but not the engineering setup to reach it. An artist had exactly the eye we needed for a feature sanity check, but could not initialize the project. A capable teammate could judge whether a workflow made sense, yet did not know what to ask a coding agent to do.

Those are founder anecdotes, not a controlled productivity study. What they revealed was a useful design problem: the person who can contribute the right human judgment is not always the person who can write the technical prompt or prepare the environment.

An AI task handoff can bridge that gap. It does not make job titles irrelevant, turn a novice into an expert, or make every task transferable. It lets an expert prepare the technical side of one bounded task while another teammate brings the access, attention, domain judgment, and real-world checks needed to carry it through.

Key takeaways

• A technical task becomes transferable when the missing skill is narrow, the outcome is bounded, and the runner has a concrete way to verify it.
• Better performance with an agent is not the same as acquiring the underlying expertise; qualified review and clear escalation boundaries still matter.
• Start with low-risk, reversible work and measure accepted outcomes, rework, review time, and abandoned attempts before widening the handoff model.

The gap is often smaller than the job title

“Can this person do engineering?” is usually the wrong question. Engineering contains many different acts: understanding a requirement, locating code, changing it, running it, noticing a visual defect, checking permissions, testing an edge case, and deciding whether the result is acceptable.

A teammate may be unqualified to design an authorization system and still be the best person to notice that a customer flow feels broken. An artist may not know the build tool and still be the strongest judge of a transition, composition, or visual regression. An operations teammate may not write the fix but may know the real sequence that reliably reproduces the bug.

The task becomes transferable when we can separate four things:

1. Domain brief: somebody who understands the problem defines the outcome, constraints, and boundaries.
2. Agent guidance: the coding agent receives the technical context, setup instructions, work request, and stop conditions.
3. Human role: the runner receives a short, concrete runbook for access, observation, judgment, QA, and escalation.
4. Acceptance: evidence returns to a qualified reviewer, who decides whether the task is actually complete.

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

This is not “give the task to somebody cheaper and hope the model handles it.” The expert's knowledge remains in the system: first in the brief, then again at review. The runner's role is real rather than ceremonial because the task names a check they are equipped to perform.

Performance with AI is not the same as expertise

The strongest research warning for this idea is also the best explanation of its promise.

In a preregistered experiment, researchers gave BCG consultants access and training with ChatGPT for data-science tasks outside their existing skill sets. The assisted consultants performed much better on the three tasks and came close to real data scientists on two of them. But when the tool was removed, they were no better than the control group at answering technical questions. The researchers' conclusion was deliberately narrow: generative AI could act as an exoskeleton for performance, but the nontechnical workers did not become interchangeable with data scientists. Read the working paper, GenAI as an Exoskeleton.

That distinction matters for Wagglet.

If the goal is to complete a bounded task safely, a persistent support structure can be valuable. If the goal is to teach somebody an independent skill, completing the task with an agent is not enough. Training needs additional mechanisms: explanation, deliberate practice, teach-back, repetition without the tool, and feedback from somebody who already understands the domain.

We should therefore say capability bridge, not automatic upskilling. The person-agent pair may be able to complete work that the person could not complete alone. That does not prove the person has acquired the underlying technical expertise.

The research says “sometimes,” not “everyone”

There is credible evidence that AI assistance can help less-experienced workers in particular settings.

A 2025 Quarterly Journal of Economics study followed the staggered rollout of an AI assistant to 5,172 customer-support agents. Productivity rose in that setting, with larger gains among novice and lower-skill agents. The assistant supplied real-time suggestions derived from prior support interactions, while the human remained responsible for the conversation. The authors also stress the boundary: this was one tool, one firm, and one occupation with a relatively stable product and set of questions. It is not evidence that the same result appears in software, art, operations, or every company. Read Generative AI at Work.

Another field experiment with 758 consultants explains why the boundary is so important. For tasks inside the model's capability frontier, AI improved several measures of performance. For the one task deliberately placed outside that frontier, AI assistance made correct answers less likely. Tasks that looked similarly difficult to people landed on different sides of what the researchers call the jagged technological frontier. Read the open-access Organization Science study.

So the promise is not “AI lets any person do any job.” It is more specific:

For a carefully selected task, expert-authored context plus agent assistance may let a different teammate contribute useful judgment and carry the work to a separate review.

That is a hypothesis worth testing task by task, not a universal staffing rule.

Three small bridges

The easiest way to understand the pattern is through the kinds of cases that motivated it. These examples describe our founder's operating experience; they still need individual factual confirmation before publication and should not be read as measured Wagglet outcomes.

An office manager helps close a small bug

Imagine a customer-facing setting that saves correctly but displays the wrong label afterward. The office manager knows the workflow, can reproduce the problem with a synthetic account, and can tell whether the corrected behavior makes sense. What they cannot do is find the component, prepare the repository, or write a reliable coding-agent prompt.

The task author supplies the technical brief: exact reproduction steps, the likely surface, what must not change, relevant authorization rules, deterministic tests, and the required delivery evidence. The agent handles setup and implementation. The office manager runs the flow before and after, checks the named cases, and stops if the change reaches beyond the small display bug. A technical owner reviews the diff, tests, and delivery before accepting it.

The office manager did not become the project's engineer. They contributed product knowledge, care, and a real verification step that the task needed.

An artist runs a feature sanity check

An artist may be unable to build the project from a fresh checkout but exceptionally qualified to judge visual rhythm, animation timing, clipping, hierarchy, and whether a new state still matches the authored design.

The task can tell the agent how to prepare and launch the exact feature state. The human runbook can name the devices, viewport sizes, gestures, and visual details to inspect. The artist records screenshots or a short video, reports what looks wrong in ordinary language, and escalates any behavioral or performance issue instead of approving around it.

Here the agent bridges tooling knowledge so the artist can apply the expertise they already had. Calling the artist “nontechnical” would miss the most important skill in the task.

The agent closes the setup gap before the work starts

Sometimes the person can do the whole human check but cannot get through installation, authentication, the correct branch, or an unfamiliar development command.

A good handoff treats readiness as its own gate. The agent verifies that it has disk access, is in the right repository and branch, can authenticate, and has an initialized project. If not, it explains the missing step in plain language and helps prepare the environment before touching the task. If the problem cannot be fixed safely from that session, it stops and says exactly what help is required.

That setup assistance is useful, but it needs boundaries. An agent should not invent credentials, weaken access controls, discard existing work, or improvise through an environment it does not understand.

Choose tasks by their verification surface

The best handoff candidate is not merely “easy.” It has a result that the assigned human and the reviewer can observe from different angles.

Before offering a task beyond its usual specialist group, ask:

Do not use this pattern to route high-risk legal, medical, financial, privacy, security, or production decisions to an unqualified runner. Do not use it when correctness is hidden, failure is irreversible, or the author cannot define what good evidence looks like. Some tasks belong with a specialist at the controls; some should remain human-only.

NIST's Generative AI Profile treats confidently false output—confabulation—as a material risk and recommends evaluating output against known ground truth with both human oversight and automated methods. It specifically calls for reviewing generated code for validity and safety. That is a useful floor, not a certification: an agent's confidence is not evidence, and a human clicking “looks good” is not a test. See the NIST Generative AI Profile.

Give the human a check, not just a chair

“Human in the loop” is often used as if human presence makes a workflow safe. It does not.

A 2025 CHI study surveyed 319 knowledge workers about 936 real examples of using generative AI. Higher confidence in AI was associated with less reported critical-thinking effort, while the work that remained shifted toward verification, integration, and task stewardship. This was a self-report survey, not a causal test of Wagglet, but it points at the right design question: if AI changes where people think, the workflow must make that new responsibility explicit. Read The Impact of Generative AI on Critical Thinking.

The runner needs to know:

• what they should see when the result is correct;
• which facts or states they can verify directly;
• what the agent is not authorized to decide;
• what evidence to attach or record;
• which surprise means “stop,” not “keep prompting”;
• who owns final acceptance.

This is why Wagglet keeps the detailed agent brief separate from the human instructions. The human side is not a compressed implementation plan. It is an operating role.

What Wagglet can make explicit today

Wagglet is built around a bounded Task Handoff: a person claims one task, gives its prepared context to an agent, and later records a delivery through a separate capability.

The current product can represent several parts of the skill-gap bridge:

• Separate instructions. LLM instructions contain the agent's actual prompt. Human instructions are shown to the runner and deliberately do not enter the copied agent prompt.
• Readiness before execution. A task can require the agent to verify the workspace, repository, branch, initialization, and authenticated Git before starting.
• A deliberately chosen runner. Claim rules can reserve a task for named people or require selected team skill tags. Widening participation does not mean removing eligibility controls.
• Human QA and proof. A task can request a human QA pass and require new screenshots or video from the current attempt. The agent can be told to leave the work running and provide concrete test ideas.
• Delivery separate from acceptance. The runner and agent record what happened. A later review decides whether the evidence meets the task. Independent acceptance ordinarily requires somebody other than the runner.

These are workflow mechanisms, not proof of a productivity outcome. Wagglet has not yet published a controlled result showing that a certain percentage of work becomes transferable, that every runner succeeds, or that review time falls. Those claims require a pilot.

For the exact current handoff mechanics, read the Wagglet Task Handoff Skill. For the two-audience task-writing pattern behind the brief and runbook, read The Dual Prompt.

Measure the bridge before widening it

A sensible pilot starts with a handful of low-risk, reversible tasks. For each attempt, record:

• the narrow gap that previously blocked the runner;
• why that runner's existing judgment was relevant;
• author preparation and reviewer time;
• clarification and escalation events;
• evidence produced at delivery;
• acceptance, rework, or abandonment;
• whether the runner could identify the important failure cases;
• what the runner and author would change next time.

Do not count a claim as completion. Do not count a delivery as acceptance. Do not compare a five-minute visual check with a two-day implementation as if they were interchangeable units. The first useful result is not a company-wide multiplier; it is a small set of receipts showing which task shapes transferred well and which did not.

The goal is also not to keep every person occupied for every minute of the day. It is to stop wasting relevant talent because one narrow technical threshold prevents someone from contributing at all.

Job titles are coarse. Tasks are specific. When we can write down the technical context, give a person a check that matches their real strengths, and preserve qualified review, some small skill gaps stop being walls.

That is the opportunity Wagglet is testing: not replacing expertise, but placing it around a human-agent pair so more capable people can carry bounded work all the way to an accountable outcome.