Does your task need a workflow or an agent?

Before choosing an agent framework, write down one piece of work that should be completed. Include the input, the expected result, and the person who will decide whether the result is acceptable. That description gives you something to reason about. A general ambition to automate operations leaves too many decisions open to make a useful architecture choice.

There is a practical distinction to keep in mind. Anthropic describes workflows as following predefined paths, while agents dynamically direct their processes and tool use. Use the fictional request process below to examine those choices before trying them on your own task.

Write a completion sentence

Imagine an internal service desk that receives requests for replacement equipment. For this exercise, the desired result is a draft ticket containing the employee's name, location, requested item, reason, and any unanswered questions. A person will review the draft before approving action. The system is not being asked to choose a supplier or place an order.

A completion sentence might read: “Prepare a reviewable equipment request using the information supplied, identify missing fields, and leave approval to the service desk.” This is narrow enough to discuss. It also exposes a few questions that a broad instruction would hide. Where does the employee record come from? What counts as a missing field? Can the preparer contact the requester, or should it only draft a question?

Answer those questions on paper before selecting tools. If your team disagrees about the task, record the disagreement. An unresolved business rule should remain visible until someone responsible makes the decision. Choosing a more flexible execution pattern does not settle what the organization wants the system to do.

Draw the fixed version first

For the fictional desk, a fixed version could read the request, check for required fields, look up the employee in a directory, and prepare a draft. If the lookup finds no match, it would flag that issue. If the request lacks a location, it would include a question for the requester. Every request would pass through the same named stages, with explicit branches for known conditions.

Write each stage on a separate line. Beside it, list the input it needs and the output it produces. The directory stage needs an employee identifier and returns a record or a failure status. The draft stage needs the request and the resolved fields. This exercise makes it possible to spot dependencies without discussing model behavior in abstract terms.

Now walk through three invented requests. The first is complete. The second omits a location. The third names an employee who is absent from the directory. If you can state the handling for each one clearly, you have a fixed candidate worth trying. You have not proved it will work, but you have specified enough behavior to build a meaningful small test.

Identify the decision that would need flexibility

Change the task slightly. Suppose the requester writes, “I need the same setup as the training room, except for the display,” and the relevant information is spread across several approved internal documents. A proposed agent version might need to choose which document to inspect next based on what it finds. That is a different planning problem from checking a fixed list of fields.

Describe that decision precisely. “Choose the next approved reference to inspect when the current reference does not identify the requested equipment” is useful. “Reason intelligently about the request” is too vague to review. A flexible step should have a named purpose, a bounded set of permitted sources, and a result the surrounding process can use.

You can then ask whether that decision occurs often enough to justify building it into the first version. For a small trial, a person might handle the unusual request while the fixed process prepares ordinary ones. Alternatively, you might test the flexible research step separately. Both are legitimate planning options in this fictional example; the choice depends on the task you are actually responsible for.

Separate finding information from taking action

For this exercise, reading an approved equipment list and ordering equipment are separate permissions. Write them in different rows. The proposed preparer may inspect the list and draft a ticket, while the reviewer decides whether the request can proceed. Keeping those responsibilities explicit helps the team discuss what the first version is allowed to do.

Use the same approach for messages. Drafting a question and sending it to an employee should be treated as distinct actions in your plan. If the system may send questions, define when, to whom, and how the conversation returns to the ticket. If it only drafts questions, describe where a person will find them. A missing detail in this handoff can make an otherwise sensible design frustrating to use.

The resulting plan might have fixed intake, a flexible document review step for certain requests, and a fixed human approval stage. You do not have to assign one pattern to the whole process merely to give it a tidy label. What matters in this exercise is that each stage has a purpose and an owner.

Write down when work should stop

Consider a directory lookup that returns two possible employees. In the fictional desk's plan, the preparer should pause and ask the reviewer to resolve the identity. It should not choose whichever record appears first. That expectation belongs in the task definition so the team can test it later.

Other stop conditions could include an unavailable reference, conflicting equipment details, or a request outside the agreed scope. Decide what the reviewer should see in each situation. A useful pause message would name the unresolved issue and preserve the information already gathered. “Unable to complete” would leave the person to repeat the investigation.

You can also set a trial limit on how much work a flexible stage attempts before returning for review. The exact limit is a design choice for your task. Record it alongside the reason for choosing it and revisit it after observing the trial. Avoid treating an arbitrary number as a universal rule for all agents.

Compare candidates on the same requests

Once you have described the fixed and flexible candidates, give both the same small collection of fictional requests. Review the draft tickets against the completion sentence. Did they preserve the supplied facts? Did they expose missing information? Did they stop at the boundary you set? Keep your observations separate from assumptions about which architecture ought to be better.

Include at least one request that the fixed version handles comfortably and one that motivated the flexible step. Otherwise, the comparison will not address your actual reason for considering an agent. Record any extra review effort as well. A draft that looks complete but takes a long time to verify may be a poor fit for the service desk's routine.

Make the first decision reversible

Your next step can be a small experiment rather than a permanent platform commitment. Document the task, the chosen pattern for each stage, the allowed actions, and the unresolved questions. Keep the initial interface and examples simple enough that a colleague can review them with you.

For the fictional service desk, the first experiment might use a fixed intake and draft process, with unusual document research returned to a person. A later experiment could test a bounded agent step against those unusual requests. Your task may call for a different order. The useful starting point remains the same: map the work closely enough that a result can be checked, then choose the pattern that deserves a trial.