AI agents that finish long tasks: the 7 pieces around the model

Where this comes from

The guide uses a simple example: a workflow that writes articles from sources, checks the claims and stores what gets approved. The logic carries over to any recurring task, from a monthly report to an account reconciliation.

Decide what the agent must leave behind

The core idea fits in one sentence: before you send the agent off, agree on what it has to deliver. The guide asks for three things.

• A result you can open. The final file, saved to an agreed location, not an answer buried in the middle of a chat.
• Evidence you can inspect. A table that ties every claim to a source, with a verdict: verified, incorrect or unresolved.
• Progress saved for tomorrow. A short note on what was done, what was decided, what is still open and the next action.

That setup around the model has a name: the harness. It is the instructions, tools, permissions, state and checks. The model picks the next step; the harness decides what it works with, what it may touch and how it proves it is done.

Three pieces decide what goes in

1. Facts that always apply. A project instructions file (CLAUDE.md) with what stays useful across tasks: where to save, which sources count, how to write. A one-off deadline or an open question does not go there; it travels with the task.
2. The procedure you repeat. A skill stores the sequence (read, draft, review, save) and is called by name with the topic of the day. Every step should end in something you can see. “Check accuracy” is vague; “save the checking table to this file” is not.
3. Access to the right sources. A connector (MCP) pulls material from the system where it lives, such as Notion. Add one only when it supports a specific step, with its allowed actions spelled out.

Notice that none of these is a cleverer prompt. They are files that live in the project and serve the next task too.

One piece decides what the agent may touch

The guide puts action rules in the execution layer, not in the wording of the request. A permissions file can deny, for instance, reading the secrets files and editing the folder of approved work. The rule applies at the tool boundary, so it does not depend on the model remembering it.

Preparing and publishing are separate actions with separate sign-offs. The agent prepares work for inspection; a person approves publication.

Two operating tips worth their weight in gold: for any write to an outside system, approve the destination and the exact content, and review again if the content changes. And after a timeout, check the destination before retrying, because the first attempt may already have gone through.

Three pieces prove it is finished

1. A reviewer that returns evidence. A separate subagent with only read and search tools checks each claim against its source and returns a table: claim, verdict, source and correction. The main agent is the one who fixes the text.
2. Effort set per job. The main session runs at medium effort, the Opus 5.5 default, and the reviewer asks for high. Writing “think harder” in the request does not change that; changing the setting does.
3. A goal with acceptance criteria. The /goal command states what must exist at the end (the draft, the table, the fixes made, the open items flagged) and when to stop and report if it cannot get there.

This is where “the agent said it was done” becomes “the agent is done.” The check looks at the saved file, not at what was said in the chat.

The progress note is the shift handover

Long tasks span sessions. The guide handles that with a plain file, updated after each meaningful stage, with six fields: task, outputs, completed work, decisions, open issues and next action.

A fresh session reads the note, opens the files it names and carries on. If it starts from scratch, the note is the problem: a decision or a file path was never written down. It is the same discipline as a good shift handover between people.

Measure on accepted work, not delivered work

An output that needs heavy repair changes the value of the whole run. That is why the guide counts review time and the corrections the output needed, not just usage.

• Keep the same task and the same acceptance criteria when you test a change.
• Change one piece at a time and compare both the saved result and its evidence.
• When a correction keeps coming back, it points to a step missing from the procedure.

The author also adds an honest caution: the token savings reported in early Opus 5.5 testing belong to that experiment. Your own savings only show up when you measure your own workflow.

What this changes in practice

The lesson for anyone putting AI into operations is that the jump to long tasks comes from the design around the agent, not from a magic model. Standing instructions, a saved procedure, controlled access to sources, rules enforced at execution, review with proof, a clear goal and a proper handover.

• An AI Analyst maps the routine and sets the acceptance criteria for each task before any agent runs.
• A Forward Deployed Engineer builds that setup inside your operation: connectors, permissions, human approval at the right points, review and progress tracking.
• Training teaches your team to read the evidence and approve with confidence, which is where trust comes from.

Reports, reconciliations, proposals, data entry and research are just examples. If a task repeats, it can be automated, and with the right harness that includes the long ones.