# How to Run a Two-Week AI Assistant Pilot Run a two-week AI assistant pilot with bounded tasks, baseline effort, quality criteria, approval rules, and an evidence-based expansion decision. By Righthand Team ยท 2026-10-08 Source: https://www.righthand.ai/blog/how-to-run-a-two-week-ai-assistant-pilot ## Quick answer Run a two-week AI assistant pilot by choosing a small set of recurring tasks, measuring your current effort, and defining acceptance criteria and authority before starting. Review outputs during the first week, improve specific workflows, and make the expansion decision from complete outcomes and supervision cost. A pilot should answer where the assistant helps your team, not merely whether it can generate impressive examples. Two weeks is a practical planning window for an initial experiment, not a guarantee that every workflow can be evaluated in that time. Choose tasks that recur often enough to observe. If a critical exception does not arise, note that limitation rather than claiming the workflow has been proven under all conditions. ## Before day one Name a pilot owner and select two or three tasks. Meeting briefs, status drafts, and feedback summaries are possible candidates when the relevant sources exist. Avoid combining many new accounts and broad autonomous actions in the initial scope. For each task, define: - The intended outcome and acceptance criteria. - Required sources and authorized account access. - Preparation and execution permissions. - Review owner and completion evidence. - Baseline human effort and expected review process. - Stop conditions for errors or unresolved risks. Keep the initial authority narrow enough that every result is inspectable. A pilot should not create accidental commitments while the team is still learning how to supervise it. ## Week one: inspect the work Provide a clear brief and an approved example where tone or format matters. Review early outputs against their sources. Record corrections specifically: unsupported claims, missing decision context, wrong status, or unsuitable recipients. Track your effort supplying inputs, reviewing, correcting, and completing unfinished steps. Separate setup time from recurring effort. Do not measure only response speed or the number of drafts produced. Include blocked tasks in the record. An assistant that correctly identifies missing approval may be handling the task responsibly, even though it cannot complete the action yet. A confident but unsupported completion claim is a different outcome and deserves separate attention. ## Week two: test the revised workflow Make targeted improvements from week-one evidence. Shorten the report format if it is too long. Clarify the source hierarchy if stale documents caused errors. Confirm account identity if a connection was ambiguous. Avoid changing every instruction at once. Repeat the selected tasks and compare like with like. If task complexity changes, note it. Keep external actions reviewed unless you have separately authorized a precise supported pattern. At the end of the week, inspect whether the correction burden decreased and whether the accepted outputs consistently met the criteria. Identify unresolved capability or access gaps rather than disguising them as prompt problems. ## An illustrative pilot decision A consultant pilots meeting briefs and client update drafts. The fictional results show that meeting preparation becomes easier to review after a format change, while client drafts still require careful correction of approval states. The consultant keeps the meeting workflow, continues reviewed client drafting, and declines to authorize automatic sending. That is a useful pilot outcome: responsibility expands where evidence supports it and remains bounded elsewhere. It is not a claim about measured Righthand performance. ## A pilot brief you can copy > Run a two-week pilot of the selected preparation workflows. Use the sources and account assignments I authorize. Keep external messages as drafts unless separately approved. Record the brief, output, corrections, unresolved steps, and available completion evidence for each task. Include my recorded briefing, review, and correction time. Prepare a midpoint review and final recommendation by workflow. Do not infer success from generated output alone or expand your own permissions. Use actual dates, owners, and task definitions before starting. Confirm any recurring schedule separately through the supported product controls. ## Frequently asked questions ### What counts as a successful pilot? Accepted outputs meet the criteria, authority is handled appropriately, and total supervision effort makes the workflow worthwhile. Evaluate those conditions for each task rather than relying on one overall score. ### What should we do with unsuccessful tasks? Diagnose the cause. Improve unclear briefs, supply missing sources, or pause unsupported and unsuitable work. Some tasks may remain useful only as reviewed preparation. ### How do we begin with Righthand? Choose tasks using [task delegation](/features/task-delegation), the [executive assistant role](/roles/executive-assistant), or the [product manager role](/roles/product-manager). Review [security](/security) and current account controls before adding work systems.