Before building an agent workflow, make its task, sources, decisions and change boundaries clear enough for another person to review.

Describe the work and its boundaries

Imagine a visual builder that connects a request, a document lookup and a proposed destination for review. In this fictional exercise, the workflow reads synthetic project notes and suggests which review queue should receive a question. Drawing those steps can make the intended sequence visible. It does not by itself establish which documents are appropriate, whether the suggestion is correct or who may act on it.

Start with the task tile in the illustration. Write a sentence that names the input, the proposed result and the endpoint. Here, the input is a question accompanied by fictional project context; the result is a suggested queue with an explanation. The endpoint is a reviewable suggestion. Sending the request, changing a record or approving the underlying work would expand that endpoint and needs its own description.

The sources tile asks what the workflow can use to support that suggestion. A project name may appear in several notes, and an older note may still look relevant after responsibility changes. Describe which source establishes the current destination and what happens when that source is missing or ambiguous. The workflow should leave that ambiguity visible rather than convert a plausible match into an unsupported decision.

The decisions tile identifies where a person needs to examine the proposed result. In the example, a reviewer compares the suggested destination with the current routing instruction. The explanation should make that comparison possible: show the relevant context, identify the supporting instruction and state any uncertainty. An attractive builder interface is helpful for arranging steps, but it cannot supply an unstated decision rule.

The change tile keeps the workflow’s assumptions available for later review. If a project changes owners, the source used for routing may need revision. If the exercise expands from suggestions to sending requests, the permitted actions and failure handling also change. Record the condition that prompts another review rather than treating the first successful demonstration as a permanent description of the work.

Test the description with distinct fictional cases. A clear instruction should lead to a supported suggestion. Conflicting notes should preserve the conflict. Missing context should leave a question for the requester or reviewer. These cases examine different boundaries; combining their outcomes into a single impression of success would make it harder to identify what needs attention. Keep the inputs and expectations visible alongside the outputs.

Examine the handoff as carefully as the generated answer. A reviewer needs enough information to accept, revise or decline the suggestion without reconstructing the whole exercise. If the workflow offers only a destination name, the reviewer may not know whether it followed a current instruction or guessed from a familiar phrase. A useful handoff connects the proposed next step to the source and decision that support it.

Choose the next change from what the exercise reveals. Clarify an ambiguous instruction, narrow the task or improve how uncertainty is presented. Do not assume every problem requires another automated step. Sometimes the useful change is to stop earlier and ask a clearer question. This guide offers a way to discuss scope; it does not establish that a particular builder or agent is ready for operational use.

About the scope map

Illustrative educational material. The diagram is a map of questions, not an analyst ranking, vendor assessment, certification or reported finding.

The four tiles are complementary questions, not scores or stages of maturity. Their arrangement does not compare products, organisations or people. Task describes the intended work; sources describe its supporting material; decisions describe the review boundary; change describes when the definition needs another look.

All examples in this guide use fictional documents and responsibilities. Adapt the questions to the work being discussed without treating the illustration as a universal approval process. A different task may require a different endpoint, source set and decision owner. Keep those choices explicit enough for a reader outside the demonstration to understand.

Continue exploring

Use the related guides to practise describing a task and making an answer’s sources reviewable. Carry forward the question that remains unresolved, rather than a broad claim that the workflow has been validated.