Before you hand an AI task to a teammate, check these three gates

A teammate has time to supervise a coding agent. Your backlog has an unfinished task. That does not automatically make the task a good handoff.

The missing piece is often eligibility: can that person access the right material, understand a bounded outcome, and give the result to someone who can judge it?

Here is a small worksheet for AI task handoff for teams. It separates requirements that must pass from scores that help prioritize eligible work.

The worksheet is a proposed process. The five-person startup and tasks below are illustrative, not reported customer results.

Start with three gates

Before scoring a task, answer these questions:

Gate	What must be written down	What makes it fail
Access	The runner can use the required repository, tools, and approved data through their own authorized access.	The task requires another person's login, inaccessible files, or data the runner may not handle.
Scope	One concrete outcome, explicit boundaries, and observable acceptance criteria.	“Improve onboarding,” an unknown dependency, or changes without a defined stopping point.
Review	A named reviewer who understands the outcome and has agreed to review it.	Nobody can verify the work, or review is assumed to happen eventually.

An unanswered gate stays pending. A failed gate rejects the handoff until the underlying issue changes.

Do not award enough points elsewhere to compensate for missing authorization or a missing reviewer.

Score only tasks that pass

Use four dimensions, each scored from zero to two:

Dimension	0	1	2
Context readiness	Important context missing	Some questions remain	Reproduction, references, and constraints supplied
Verification	Mostly subjective	Manual checks defined	Repeatable checks and expected outcomes defined
Change containment	Broad dependencies	Several connected areas	Narrow change with explicit exclusions
Runner readiness	Cannot supervise this work	Needs scheduled assistance	Can explain, supervise, and stop the task

For this example, six out of eight makes a task a candidate. This threshold is a team choice, not a validated predictor of success.

A candidate still needs the runner to accept the work. Having spare tool allowance does not establish available attention or competence.

Work through a five-person example

Imagine this team:

• Priya: backend engineer and task author.
• Leo: full-stack engineer and proposed runner.
• Maya: QA engineer and reviewer.
• Sam: designer.
• Noor: founder and product lead.

Priya has three overflow tasks:

Task	Gates	Score	Decision
Add a regression test for a documented CSV parsing bug using synthetic fixtures	All pass	8/8	Candidate for Leo
Investigate a customer export available only through Priya's private access	Access fails	Not scored	Hold until an approved source and access path exist
“Improve the onboarding experience”	Scope and review fail	Not scored	Rewrite the task before assigning it

The worksheet selects a bounded regression-test task. It does not prove that the task will succeed or that Leo's tools can finish it within a particular allowance.

Write the handoff before assigning it

A reusable brief can be plain YAML:

task: Reject malformed CSV rows without losing valid rows

author: Priya
runner: Leo
reviewer: Maya

access:
  repository: Runner's existing authorized repository access
  data: Synthetic CSV fixtures only
  tools: Runner's own authorized tools

outcome:
  - Reproduce the documented parsing failure
  - Add a regression test
  - Make the smallest required parser change

out_of_scope:
  - Production exports
  - Database migrations
  - Parser API redesign
  - Deployment

acceptance:
  - Malformed rows produce the documented error
  - Valid fixtures preserve their expected parsed values
  - Relevant existing tests pass

stop_if:
  - Real customer data becomes necessary
  - The fix requires an API or schema change
  - A required dependency or permission is missing

delivery:
  - Proposed patch
  - Commands run and actual results
  - Remaining uncertainty

review:
  - Maya checks the reproduction and acceptance criteria
  - Acceptance does not authorize deployment

Replace every illustrative detail with the actual repository, reproduction, and expected behavior before use.

Keep preparation, execution, and acceptance separate

Priya prepares the task and chooses what context may be shared. Leo executes it with his own authorized tools, supervises the agent, and stops when the brief no longer applies. Maya judges the evidence against the acceptance criteria.

Delivery means that a result is available for review. It does not mean accepted, merged, or deployed.

The background to this distinction is described in Wagglet's article on using unused Claude Code and Codex capacity. The transferable unit is a prepared task; accounts and credentials stay with their owners.

For an initial pilot, record preparation time, review time, rejected handoffs, rework, and accepted outcomes. Keep failed attempts in the record. Otherwise, a worksheet intended to reduce coordination can quietly become another dashboard to optimize.

Disclosure: This article was prepared with AI assistance. I work at Rockbite, which makes Wagglet.