The example below is hypothetical and does not report a production result.
An AI task handoff for teams needs a queue that rewards useful outcomes. Token use measures an input. It cannot tell you whether a migration was necessary, a bug was fixed, or a reviewer can reproduce the result.
Use four fields before assigning work: impact, risk, readiness, and verification. Keep the last three visible instead of hiding every judgment inside a single priority score.
Start with gates
Readiness means the runner has the necessary repository access, environment instructions, and a bounded request. Verification means someone can describe the evidence required for acceptance. If either is missing, put the task in preparation. A high-impact request does not become executable because it earned a large number.
Risk describes the potential cost of a mistake. A public typo correction and a billing migration should not share an approval route. High-risk work needs its specialist and release controls before it enters the ready queue.
Among ready tasks, rank impact first and use expected review effort as a tie-breaker. This is a starting rubric, not a universal scoring formula:
| Field | Low | Medium | High |
|---|---|---|---|
| Impact | Local convenience | Repeated team friction | User-facing failure or blocker |
| Risk | Reversible text change | Bounded behavior change | Data, access, or release consequences |
| Readiness | Missing owner or access | One unresolved dependency | Scope, access, and environment ready |
| Verification | Subjective request | Evidence partly specified | Named checks and reviewer |
Copy a task card
outcome: Export button stays disabled while an export is running
scope: Export panel and its existing interaction tests
excluded: Export API, file format, unrelated styling
impact: Repeated duplicate export requests
risk: Medium; changes a user interaction
prepared_by: Product engineer
runner: Teammate with authorized repository and agent access
reviewer: Export-panel maintainer
acceptance:
- Second click during an export starts no additional request
- Button becomes available after success or failure
- Keyboard activation follows the same rule
evidence:
- Focused diff
- Reproduction steps and observed outcomes
- Test commands, results, and any skipped checks
stop_when:
- Fix requires changing the export API contract
The author prepares the card and checks that the requested behavior is actually desired. The runner executes it with their own authorized tools and access. The maintainer judges the evidence. A deployment owner decides whether and when the accepted change ships. These can be overlapping people on a small team, but the decisions should still be explicit.
Work one handoff
Imagine three requests: polish a tooltip, prevent duplicate exports, and redesign the export API. The tooltip is ready and low risk but has limited impact. The duplicate-request fix has a clear failure and a bounded test. The API redesign has an important goal but no compatibility decision.
Prepare the redesign before assigning it. Put the bounded fix first among ready work. Keep the tooltip available for a smaller work window. Nothing in that ordering depends on which request consumes the most tokens.
If the runner discovers that the duplicate originates in the server rather than the panel, they should stop and return the evidence. That is useful progress even without a patch. Rewarding only merged changes would push them toward a superficial client-side fix.
Review the outcome and the rubric
A reviewer should be able to repeat the relevant checks without reconstructing a long agent conversation. Record a verdict, the evidence used, and any remaining limits. Do not turn a passing test into a claim that every export path is safe.
The Wagglet discussion of bounties and rewards is a useful context for designing incentives around accepted work. This template is an independent example, not a description of an automatic scoring feature.
Try the rubric on a small queue. If apparently ready tasks repeatedly need clarification, improve preparation. If review dominates the work, tighten scope. Treat those observations as workflow feedback, not a ranking of people's value.
Top comments (0)