Choose your first AI agent workflow: support, inquiries, or operations

Start by writing the acceptance decision for your first AI agent task. Who will review the result, what will they check, and what would make them reject it? Then choose a narrow piece of work that fits that decision: a support reply draft, an inquiry summary, or a proposed entry in an operational worksheet.

Everything below is our proposed editorial workflow, including the examples, selection rules, measurements, and release gates. Treat it as a planning template for your own experiment. We do not present it as a validated scoring model, a universal business practice, or a promise of savings. In all three examples, a person approves the output before it is used.

Write the output contract before choosing a department

For this exercise, use a single page to describe the task. Name the input, permitted reference material, required output, reviewer, and stopping condition. Add one example of an acceptable result and another that should be rejected. Keep the initial assignment specific enough that the reviewer can explain their decision against the page.

Consider this hypothetical support assignment: “Draft an answer about which service package includes a named feature. Use only the approved package descriptions. If the feature is not documented, prepare a question for the support owner.” The output contract should specify whether the draft must include a reference to the relevant passage and how to label unanswered questions.

For inquiry qualification, write a different contract: “Prepare a structured summary of the sender’s stated request, requested timing, and unanswered questions.” For an operations task, try: “Prepare a draft worksheet row from this approved intake note, leaving unspecified fields blank.” Avoid combining those assignments into a single initial pilot.

As our working convention, reserve the word “complete” for an output that passes review or follows the agreed handoff rule. Keep “generated” as a separate status. Before moving on, ask the proposed reviewer to apply the contract to two sample outputs and explain any disagreement.

Build a shortlist of three bounded tasks

Support: draft one category of answer. Choose a topic such as package contents or the steps described in an approved help article. Specify the reference documents and the scope of the response. In our proposed pilot, exclude making exceptions, changing terms, and promising actions outside the written material. Require a handoff when the answer cannot be supported.

Inquiry qualification: organize the request. Choose descriptive fields rather than an unexplained score. For example, request type, stated project scope, requested timing, and information still needed. Require the draft to distinguish what the sender actually said from a question your team would like to ask. Assign the decision about follow-up to a named person.

Operations: prepare a draft record. Choose one input format and one output template. Require a traceable reference for each populated field. Include a rule for conflicting values: show both and request a decision. Keep approval of the final record with the reviewer during this exercise.

Compare candidates at the same level of detail. Do not put “all customer service” beside “prepare one worksheet row.” Give each candidate one input category, one output, and one review decision. If the assignment needs several unrelated approvals, split it into separate candidates before evaluating it.

Choose with a readiness worksheet

Our proposed selection method uses five questions. Mark each one “ready,” “needs work,” or “unresolved,” and attach a concrete artifact or decision. These labels are an editorial convention, not a prediction of performance.

1. Can we state the boundary? Attach the task contract and list excluded actions.
2. Have we selected the reference material? Identify the approved documents and their versions.
3. Can we judge the output? Attach an example answer or completed template and the acceptance criteria.
4. Have we defined exceptions? Write the exact condition for asking a person to take over.
5. Does someone own the experiment? Name the reviewer and the person authorized to change the scope.

Select a candidate only after every question has a written answer. If several qualify, our suggested tie-breaker is the task for which the reviewer can give the clearest explanation of an acceptance decision. If none qualify, spend the next work session preparing the missing material rather than setting a launch date.

Keep commercial expectations in a separate column. Record your proposed budget and any hoped-for outcome as hypotheses. Do not turn an unmeasured expectation into the reason a candidate receives a “ready” label. Revisit those expectations after reviewing actual pilot records.

Be precise about what the sources establish

Google’s guidance on generative AI content says that generated outputs can contain inaccuracies. Google’s generative AI content guidance.

That guidance also calls for manual fact-checking and review of AI-generated content before publication, including relevant metadata. Its stated context is content on websites. Google’s review guidance.

Our recommendation to review support drafts, inquiry summaries, and operational records is a separate editorial choice for this pilot. The Google documentation does not establish which of those business tasks your team should choose, nor does it validate the readiness worksheet above.

Google’s people-first content guidance suggests asking trusted people who are unaffiliated with a site for an honest assessment of its content. Google’s content self-assessment guidance. For our proposed business workflow, invite someone who did not write the task instructions to review a sample using the same acceptance criteria. Record disagreements and decide whether to revise the instructions or the criteria before continuing.

Run a rehearsal with deliberate exceptions

Prepare the evaluation examples before examining the generated results. Include ordinary inputs, incomplete inputs, and conflicting inputs. For each example, write the behavior you want the reviewer to accept. Keep a copy of the instructions and reference material used for that run.

For the support candidate, include a question whose answer is absent from the approved document. Specify that a handoff is the expected result. For the inquiry candidate, include a sender who provides a project description but no requested timing. Expect the timing field to remain unspecified and a follow-up question to be proposed. For the operations candidate, supply two conflicting values and expect a flagged discrepancy.

Review content accuracy, required-field completeness, and exception handling separately. Count accepted drafts, drafts needing edits, rejected drafts, and appropriate handoffs under definitions agreed before the run. Record review time and the nature of corrections. If you compare the pilot with a manual approach, define the start and end points of both measurements in advance.

Choose a release gate before running the examples. As an optional convention, require every deliberately missing-answer case to receive the expected handoff and require no unsupported additions in the reviewed sample. Set additional criteria for your own assignment. Describe the result as an observation about that sample, without extending it into a guarantee about future work.

Make one explicit decision after the pilot

End the exercise with one of three decisions: revise the instructions, repeat the rehearsal, or add one narrowly defined category to the assignment. Attach examples that explain the decision. When you change the input format, reference material, or acceptance criteria, note the new version and identify which examples you want to run again.

Before configuring a tool, assemble a handover packet: the output contract, reference documents, evaluation examples, exception rule, and named owner. Our final checklist is to ask whether another reviewer could use that packet to explain the same acceptance decisions. Add clarification wherever the answer is uncertain.

The Max AI registration page describes Max AI as an operating system for AI agents. Max AI registration. Once your pilot packet is ready, use it as your own requirements document when evaluating the service and deciding how to configure your first task. Start with one output, one reviewer, and one documented decision about what comes next.