How to choose your first agent workflow

The first agent workflow should teach your team something useful without demanding that you redesign the entire company. Start with a task you can observe, explain, and review. A broad ambition such as improving customer service is too large to test. Preparing a draft answer from three approved documents is small enough to inspect, yet substantial enough to reveal whether the approach helps.

Before selecting technology, write down several recurring tasks from the last week. Use verbs and outputs: classify incoming requests, prepare a meeting brief, gather references for a support answer, or reconcile fields between two internal records. Avoid job titles such as sales agent or research agent. A job title hides many different decisions inside a phrase that sounds specific.

Watch the manual version first

Ask the person who does the work to demonstrate a recent example. Follow the request from arrival to completion. Which information did they trust? Which application did they open next? Where did they stop to ask someone else? Capture the sequence and the reason for each decision. An agent built around an imagined process may automate a tidy diagram while leaving the actual work untouched.

Include at least one difficult example in this observation. The ordinary case shows the likely happy path, but the exception often reveals the true boundary. A missing account identifier might require a person to contact the requester. A disagreement between two documents might require a policy owner. If these cases are frequent, they belong in the design from the beginning rather than in a later list of edge cases.

Separate interpretation from routine mechanics

Some parts of a task may already be straightforward rules. Moving a file after a known event, checking whether a required field is blank, or calculating a total may not require model judgment. Identify where language interpretation or flexible information gathering would add value. Keep routine mechanics explicit so the team can tell which behavior is predictable code and which behavior needs evaluation.

Anthropic's architecture article describes a useful distinction between predefined workflows and agents that choose their own steps. Use that distinction as a question, not a badge. Does the job need freedom to select a route, or does it mainly need a model within a known sequence? The answer can help keep the first pilot proportionate to the problem.

Compare candidates on five practical dimensions

For each task, assess how often it occurs, how available its inputs are, how easy the output is to check, how costly an error would be, and how much review the result requires. Write a short explanation for each assessment. A numerical score can help organize a conversation, but it should not conceal a missing source of data or a serious consequence behind a reassuring average.

A useful first candidate usually has accessible inputs and an output an employee can review quickly. Frequency matters because the team needs enough examples to learn from. Consequences matter because a small-looking action can still create a difficult recovery. Review effort matters because a draft that takes longer to check than to write is not a useful shortcut for that operator.

Consider three fictional options for a small services company. The first prepares an internal meeting brief from project notes. The second sends revised commercial terms to customers. The third sorts internal requests into a review queue. The meeting brief may be a good candidate if sources are consistent and staff can verify it. The commercial terms introduce commitments that deserve a different level of control. Request sorting could work if wrong routing is easy to detect and correct.

Define a result you can recognize

For the chosen task, describe what a useful output contains. An internal meeting brief might require the project name, the latest agreed milestone, unresolved decisions, and source links. It should distinguish confirmed dates from proposed dates. It should also have an explicit outcome when the relevant source is unavailable. These details make success more concrete than saying the brief should be accurate and helpful.

Write one example by hand. Give it to the person who will review future results and ask what they would change. This small exercise can expose disagreements before anyone writes a prompt. Perhaps the project lead wants a list of decisions, while the operations manager wants a summary of activity. Both are reasonable, but they describe different outputs and should not be left for a model to reconcile silently.

Look for the hidden integration work

The model call may be a small part of the project. Check how the workflow will identify the right record, retrieve the current document, authenticate to the source system, and save its result. Ask who can grant access and whether a test environment exists. A promising candidate can become a poor first pilot if every input requires a new integration or a manual export.

Also inspect the information itself. Does the knowledge base contain multiple versions of the same policy? Are project names used consistently? Is an employee expected to infer a missing identifier from context? A short data-cleanup task may do more for the pilot than another round of prompt changes. Record these prerequisites so the team can make an honest decision about effort.

Estimate the whole task cost

Measure a few manual runs, including review and correction. Then decide what the pilot will measure: time to a usable brief, number of unsupported statements, proportion needing substantial edits, or time spent resolving exceptions. These are proposed measures, not promised improvements. The pilot exists to discover whether the change helps under your actual conditions.

Do not measure only the time until the model produces text. A fast draft may leave the employee checking every detail. Count the time spent opening source links, correcting fields, retrying a failed run, and handling a request that falls outside the workflow. If the system shifts work to another person, include that person's time too. The total experience is what determines whether the team will keep using it.

Set a small evaluation before building more

Collect a compact set of representative inputs with the required outcomes. Include ordinary requests, missing information, conflicting documents, and one out-of-scope request. Preserve some examples for a later check so you do not tune exclusively to the cases already on your screen. The set does not prove universal reliability, but it makes the next discussion more grounded than comparing favorite demos.

The Anthropic guide to agent evaluations explains why outcomes deserve attention alongside run transcripts. For your pilot, inspect the saved result and any state changes, not only the agent's final message. A workflow that says it created a brief should leave the expected brief in the expected place, with the correct permissions and review status.

Make the decision reversible

Choose a pilot period, a responsible owner, and a way to return to the manual process. Start with an internal draft or queue where feasible. Define the conditions that would pause the pilot, such as repeated unsupported claims or a connection that writes to the wrong record. The owner should be able to act on those conditions without convening a new project meeting.

Your next step is a one-page task map. Put the trigger at the top, the desired output at the bottom, and the information sources and human decisions between them. If the team cannot agree on that map, resolve the disagreement before choosing a framework. A well-chosen first workflow creates evidence for the next decision, including the possibility that a simpler automation is sufficient.