Field notes

Plan work an
agent can finish.

Three practical guides: choose a first workflow, write a task brief, and test the team before expanding it.

Working guides

Leave with a brief you can use.

01 / Choose a workflow with a checkable result

Start with a task that has known inputs, a repeatable output, and someone who can judge it. “Prepare a weekly customer-question brief” is a better starting scope than “manage customer experience.”

Input

Twenty anonymised support questions from the same week, the current help guide, and the product's release notes. Give each question an ID so the output can point back to it.

Output

A brief of no more than 600 words: the five most frequent themes, counts, source IDs, missing answers, and three suggested documentation changes.

Review

A support lead checks every count and recommendation against the inputs. Customer replies, ticket changes, and publication stay outside the task.

Keep one unit of work
One week's questions become one brief. Separate drafting a help article into its own task so a bad draft does not block the research.
Assign only the roles you need
A Researcher groups the questions; a Content creator writes the brief; you review the result. Combine the first two roles for a smaller pilot.
Define failure before starting
A brief fails review if a theme has no source IDs, counts do not add up, or a recommendation claims an unsupported product capability. Ask for corrections before reusing it.

How task ownership and review fit together

02 / Copy a task brief with clear boundaries

Replace the bracketed fields, then attach the source material. A good brief says what to produce, what counts as done, and when to stop and ask.

Task: [Prepare the weekly customer-question brief]
Outcome: [Help the support lead choose documentation fixes]
Owner: [Researcher]
Reviewer: [Support lead]
Inputs: [Ticket IDs Q01–Q20, help guide, release notes]
Deliverable: [600-word brief with themes, counts, source IDs]
Done when:
- Every finding links to an input.
- Counts match the source sample.
- Assumptions and missing information are listed.
Boundaries: Do not send replies, edit tickets, or publish.
If blocked: List the missing input and ask the reviewer.
Handoff: Submit the draft and source list for review.

Example correction: Replace “make this useful” with “include the three most common unanswered questions, each with a ticket ID.” That turns a preference into a check the reviewer can perform.

For a recurring task, keep the brief stable and update only the input period, files, and reviewer. Change the instructions when review finds a recurring problem; record why you changed them.

Turn a good brief into a playbook

03 / Test a small team before increasing the budget

Run the same brief on a small set of representative inputs. Track the work unit, review effort, and corrections together. More agents are useful only if the handoffs improve the result.

Record	Example for one brief	What it tells you
Input size	20 customer questions	Whether next week's workload is comparable.
Review effort	Minutes spent checking sources and editing	Whether the draft actually saves work.
Corrections	Unsupported findings, wrong counts, missing inputs	Whether to improve the brief or change the role.
Run cost	Model, tool, retry, and runtime usage when available	The cost of an accepted result, including failed attempts.

In setup, select Research & strategy and Create content, choose Light workload, and start with two agents. Compare Balanced with Higher capability while leaving the work and team size unchanged. Then compare Weekly and Monthly to understand the planning period.

The displayed rates are illustrative, so use this comparison to test the planning controls. Before buying a real service, replace the sample assumptions with measured usage, a price quote, and your own review time.

Read the spending model

Reference