Complex Tasks for AI Agents: Steps and Checkpoints

You ask an agent, "Analyze these 200 pieces of customer feedback, find the most important problems, and suggest improvements," and you may get something like this (simulated):

Users are mainly unhappy with price, delivery and support. Optimize pricing, improve logistics efficiency and strengthen support training.

It reads smoothly, but it has no category results, no frequencies and no customer quotes, so a reader can't check the conclusion. When an agent produces the final result from one sentence, the dependencies between steps and the checkpoints in a real task are easy to skip.

Preparing for a client meeting, writing a project retrospective, handling customer feedback, drafting a course outline: these tasks usually move forward in steps, for example:

Gather information -> pick out key points -> produce a result -> check risks -> hand to a person to confirm

The trouble is that one sentence leaves out a lot: who the client is, what was discussed before, which conclusions need evidence, and which steps depend on the result of the one before.

A better approach splits the task into concrete steps, writes the input and output of each, and lets every step pick up what the last one produced. Then it ranks problems, looking at both how often they occur and how serious they are.

Checkpoints go before the expensive steps, so a wrong category at the start is caught early and nobody redoes the whole report after it is written.

01 What a one-sentence task leaves out

Consider a common request: "Help me prepare for tomorrow's client meeting." It states a goal but leaves out the steps needed to reach it. Who is the client? What was discussed before? What's the goal of the meeting? What does the client care about most? Which commitments are off the table? What should come out of the meeting?

If the agent takes that sentence and hands you an agenda right away, the client's background, past conversations, risk limits and approval points have probably not been checked. First break the task into steps that depend on one another:

1. Confirm the meeting goal
2. Review the client's background and past conversations
3. Pull out the questions the client cares about
4. Prepare the agenda
5. Draft likely questions and answer points
6. Mark what can't be promised or needs confirmation
7. Output a meeting preparation checklist

This order builds the facts and the goal first, then produces the agenda and answer points, and finally checks the limits on promises, which makes it easy to verify the preparation item by item.

02 In a good flow, every step can be checked

Design the flow so every step can be checked. Breaking the task into concrete actions makes guesses and gaps easier to spot. Compare two ways of writing it:

Back to those 200 pieces of feedback. Ordered by how the evidence is built, the task splits like this:

Step 1: Read the feedback, drop irrelevant items and duplicate imports of the same entry, keep the original IDs.
Step 2: Classify by issue type, such as price, delivery, features, support and usability.
Step 3: Count how many pieces of feedback fall under each type, using one consistent rule.
Step 4: Pull a representative quote for each frequent issue.
Step 5: Separate firm conclusions from insufficient information.
Step 6: Propose improvements based on the evidence.
Step 7: Output an issue table, the evidence and the suggestions.

De-duplication handles only the case where the same record was imported twice. If different customers all say "delivery is slow," those are separate pieces of feedback, and you keep them even when the wording is identical. Before counting, agree on a rule: if one piece of feedback mentions both delivery and support, count delivery +1 and support +1, so the totals across categories may add up to more than 200. Settle the counting rule first, and the numbers become comparable.

03 Priority has two dimensions

Categories, counts and representative quotes can all be checked against the original feedback. To rank priority, look at two dimensions:

Frequency: 120 say delivery is slow   -> frequent, worth analyzing
Severity:  2 say they saw someone else's order -> rare, but check right away for unauthorized access

"Most important" comes from both dimensions together, and ranking by count alone would miss serious problems. Until they're verified, record those 2 pieces of feedback as "serious risk leads," and decide about a data leak after checking. A flow that builds evidence before it gives suggestions makes skipped steps and gaps easy to see.

04 Steps connect through inputs and outputs

Spell out each step's input and output, and the next step can pick up the previous result:

Clear inputs cut down on what the agent has to guess, and clear outputs make later steps easier to carry out. Suppose the table is done and the task breaks off right there. Where does it pick up next time? That's what task state is for: after each step, record what's done, the key decisions and the next step, so that when the task resumes the agent can find the breakpoint and the basis for what follows.

For recording progress across steps, Anthropic describes structured note-taking: persist key state outside the context window and load it again when work continues.

05 Where to put checkpoints

How does one classification error spread? If the classification wrongly labels "delivery delay" as "support attitude" at the start, every count and suggestion after it goes wrong too. Fixing it after the report is written means redoing many steps. So set checkpoints that catch errors before the costly steps. A checkpoint can be simple:

After classification, show the classification rules and examples first.
When information is insufficient, stop producing firm conclusions.
For promises, prices, contracts and refunds, wait for human confirmation.
Before final output, check that every suggestion has a basis.

Checkpoints usually go in three kinds of places:

A checkpoint also has to say what counts as passing. If the feedback says "delivery was late" and the table labels it "support attitude," first fix the classification, recount the affected categories, and then check the suggestions that were made from the old numbers. Keep "executed" apart from "passed": a generated table only shows that the step ran, and only when the classification matches the original text does it pass and move into the counts.

If one agent can't keep up and the work needs to be split across several, see when to use multiple agents. A flow can be short, but keep the key checkpoints so problems get caught in time.

Anthropic’s prompt-chaining workflow also adds programmatic checks between steps so later processing builds on results that have passed a check.