A reusable agent skill should explain what counts as finished work, what evidence justifies another attempt and what to return when the run must stop. Keep those decisions separate. An agent that reaches its limit has not necessarily completed the task, while an agent that has completed and checked the task should not continue polishing indefinitely.
For teams maintaining actual SKILL.md packages, this is a design problem across instructions and execution controls. Put the task-specific progress rule in the skill. Put enforceable resource limits in the application or runtime that runs it. Check how the two interact in the intended assistant surface.
The workflow below is an editorial proposal. Its supplier documents, limits and outcomes are fictional. We have not installed a skill, run an agent experiment or tested compatibility between products for this article.
Distinguish a behavioral instruction from an execution control
The Agent Skills specification defines a package containing SKILL.md, with optional scripts, references and assets. Its body contains instructions. The specification does not define a portable, enforced maximum-iterations field. Adding a limit to prose or custom metadata does not establish that a host will count attempts or terminate execution.
For example, a skill might tell the agent to stop after repeated searches return no relevant new evidence. That instruction helps describe the intended behavior. A runtime limit separately determines when further execution is unavailable, including when the agent fails to follow that instruction.
Specify both deliberately. A business owner can define an acceptable partial comparison. A developer can identify the counters, timeouts and usage controls supported by the actual runtime. If a hosted assistant does not expose a needed control, record that limitation rather than claiming the skill supplies it.
Research identifies repetition and premature termination
The October 2025 revision of Why Do Multi-Agent LLM Systems Fail? develops a failure taxonomy from execution traces and studies it across multi-agent frameworks. It distinguishes unnecessary step repetition, failure to recognize termination conditions and premature termination. These are different failure categories: stopping more aggressively does not automatically solve all of them.
The paper concerns the systems, models and tasks evaluated in that research. Its taxonomy informs our review questions; it does not validate this article’s proposed stopping policy or establish current failure rates for single-agent skills. We do not import its benchmark percentages as a forecast.
Anthropic’s December 2024 engineering guide recommends environmental feedback, checkpoints and stopping conditions such as iteration limits. This is vendor practitioner guidance. The page itself warns that its tooling landscape has changed and points to newer managed-agent material. We use its general control principle, not its historical product descriptions as a current compatibility claim.
Together, these sources suggest a useful design question: what observation distinguishes a productive next step from simply doing another step?
Define progress against the business task
Consider a fictional skill that compares two supplier product sheets using an approved document set. The requested table must identify the exact product model, power requirement and operating-temperature range, with a source location for each. It may save a draft comparison but cannot contact suppliers or make a purchasing commitment.
Completion means that every required field is supported for the correct model, or that the agreed output explicitly identifies unresolved fields if partial delivery is allowed. Opening a document, producing a table or announcing confidence is not the same as satisfying those conditions.
For this task, useful progress could be finding an applicable model-specific passage, resolving a conflict between revisions or verifying that a candidate passage concerns the wrong model and can be excluded. Progress need not always increase the number of completed cells. A justified exclusion can narrow the problem.
By contrast, returning to the same sheet and repeating the same unsupported value does not resolve the missing field. Rephrasing a search is not, by itself, evidence that the search advanced the comparison. Record a short observation about what changed in the evidence, rather than asking the model to rate its own effort.
Use different stopping outcomes for different evidence
The following table proposes a policy for the fictional comparison. It is not a standard Agent Skills extension or a universal threshold.
| Condition observed | Next decision | Result to preserve |
|---|---|---|
| All required fields checked against applicable passages | Finish the comparison | Checked table and source locations |
| A new applicable passage resolves an open field | Continue to the remaining checks | Updated table and evidence |
| A search excludes a wrong-model document | Continue if a relevant next source remains within scope | Exclusion reason and remaining question |
| Repeated attempts add no relevant evidence | Stop the stalled part under the agreed policy | Open field, attempts and specific blocker |
| Execution budget is exhausted | End further task work through the runtime’s supported handling | Partial artifact and uncompleted checks |
| An external action has an uncertain outcome | Reconcile through the supported procedure | Explicit uncertainty; no blind repetition |
For an initial controlled exercise, an owner might choose to review the stalled part after two consecutive attempts add no relevant evidence. For this exercise, one attempt means one planned lookup and inspection of its returned material, rather than each low-level request. That number is invented for illustration. It should be adjusted using actual task behavior, including false stops, rather than treated as a research-backed optimum.
The rule should also allow independent work to continue when appropriate. A missing temperature range for one product need not prevent checking the other product’s power requirement. Preserve the unresolved cell instead of restarting the whole comparison or inventing a value to make the table look complete.
Enforce the limit you actually intend to control
A counter’s unit matters. LangGraph’s Graph API documentation describes a recursion limit in graph super-steps, with GraphRecursionError when that limit is reached. Parallel nodes can participate in the same super-step. This is not a direct cap on individual model calls, tool requests, elapsed time or monetary cost.
The same documentation describes proactive handling using remaining-step information. That can support a controlled exit before an error, but the application still has to implement its routing and partial-result behavior. We have not executed those examples here.
For another runtime, inspect its own definitions. Count retries inside connectors and helpers where they affect the resource being controlled. A parent agent’s short loop may still invoke a helper that performs many requests. Separate limits may be necessary for elapsed duration, tool calls or usage; one counter should not be advertised as controlling all of them.
Reserve room for saving status and reporting what remains, using the runtime’s supported lifecycle. Do not depend solely on a final model response after a hard cutoff. Also check what cancellation means for work already dispatched. Ending the conversation does not prove that a remote operation has been undone. Our retry-safety guide covers that separate outcome problem.
Test false stops as well as loops
Prepare controlled cases before editing the stopping instructions. Include a comparison that finishes quickly, a missing field with no applicable source, a wrong-model sheet and a case where the relevant passage appears only after several legitimate inspection steps.
Inspect whether the policy stops repetitive work without interrupting the last case prematurely. Also include a finished, verified table: the agent should return it rather than consume the remaining allowance on optional rewrites. A limit is a ceiling, not a target.
Record why each run ended: verified completion, unresolved evidence, resource limit, environment failure or another defined outcome. Keep that status separate from whether a draft artifact exists. A partial table saved successfully can still be an incomplete task.
When the run stops, preserve the artifact revision, verified fields, unresolved questions and the evidence needed to resume. Our unfinished-work handoff guide explains that continuation record. Here the additional acceptance question is whether the workflow stopped for the right reason at the right boundary.
Start with one skill whose repeated work is visible in traces. Define a task-specific progress observation, pair it with an enforceable runtime boundary and test both productive continuation and justified stopping. Keep the policy only if it improves the completion behavior you actually observe.