Files
crewAI/docs/edge/en/tools/automation/waittool.mdx
João Moura 97981ed31b
Some checks failed
CodeQL Advanced / Analyze (actions) (push) Has been cancelled
CodeQL Advanced / Analyze (python) (push) Has been cancelled
Check Documentation Broken Links / Check broken links (push) Has been cancelled
Vulnerability Scan / pip-audit (push) Has been cancelled
feat(tools): add WaitTool for pausing on long-running jobs (#6690)
* feat(tools): add WaitTool for pausing on long-running jobs

Agents that kick off out-of-band work (a sandbox build, a deployment, an
async API job) have no way to let clock time pass: they either poll in a
tight loop or give up before the work finishes.

WaitTool pauses for a given number of seconds, with an optional reason
echoed back for traces. A single call waits at most max_seconds (default
300, configurable). Longer requests are clamped to the cap and the result
says so, so the model calls again rather than failing. Sync and async
execution are both implemented; stdlib only, no new dependencies.

The tool description spells out when to reach for it (builds, deploys,
batch jobs, async polling, backoff) and when not to, so models pick it up
for the right reason.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(tools): enforce non-negative wait on positional calls, fix doc snippets

BaseTool.run() skips args_schema validation when called with positional
arguments, so tool.run(-5) reached time.sleep(-5) and failed with an
unrelated error. _resolve_duration now enforces the seconds >= 0 contract
itself, covered for both run() and arun().

Docs and README examples are now self-contained: check_build_status_tool
is defined with the @tool decorator instead of referenced out of nowhere,
and the async example awaits inside asyncio.run() rather than at top level.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs: point the wait tool card at the edge path

Unprefixed links resolve against the default docs version (v1.15.7),
where the wait tool page does not exist, so the card 404'd in the broken
link check. Prefixing with /edge matches how other edge pages link.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(tools): never cache waits and keep the advertised cap accurate

Two issues from review, both confirmed against the code.

Waits inherited the default cache_function, which always allows caching.
With crew cache enabled, a repeat call with the same arguments returned
"Waited N seconds." straight from the cache without sleeping, turning a
poll-wait-check loop into a busy loop. WaitTool now declares a
cache_function that always refuses.

The description advertising the cap was only rebuilt when max_seconds
reached __init__ without an explicit description. Passing both (as a
platform building from tool.specs.json init params would), calling
model_validate, or assigning max_seconds left the text claiming 300
seconds while clamping to something else. A model_validator now derives
the description from max_seconds on construction, validation, and
assignment, and leaves a caller-supplied description untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(tools): reject NaN waits and pluralize single-second results

_resolve_duration now rejects NaN with its own message instead of letting
time.sleep raise "Invalid value NaN (not a number)" from a positional
call. Infinity keeps clamping to the cap like any other oversized wait.

Result and description text no longer says "1 seconds". Tests use the
public WaitTool().description as the baseline rather than reaching for
module-private helpers.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-27 17:12:27 -07:00

125 lines
3.9 KiB
Plaintext

---
title: Wait Tool
description: The `WaitTool` lets an agent pause before checking a long-running job again.
icon: hourglass-half
mode: "wide"
---
## Overview
The `WaitTool` pauses execution for a given number of seconds. It exists because agents that
kick off long-running work — a sandbox build, a deployment, a batch import, an async API job —
otherwise have no way to let time pass. Without it, an agent either polls in a tight loop or
gives up before the work finishes.
The tool takes no API key and has no dependencies beyond the standard library.
## When to Use It
The tool's description tells the model to reach for it when out-of-band work needs real time
to progress:
- A sandbox build, test run, or script that is still executing
- A deployment or provisioning step that is still rolling out
- A batch import, export, or training job
- An async API that returned a job id to poll later
- A rate limit or backoff that has to cool down before retrying
The pattern the model is steered toward is: start the job, wait, check status, wait again if it
is still running. The description also tells it *not* to wait to pace a conversation or when the
information it needs is already available — waiting only lets clock time pass, it does not
advance or check the job.
## Installation
The tool ships with `crewai-tools`:
```shell
uv add crewai-tools
```
## Example
```python Code
from crewai import Agent, Crew, Task
from crewai.tools import tool
from crewai_tools import WaitTool
wait_tool = WaitTool()
@tool("Check build status")
def check_build_status_tool(build_id: str) -> str:
"""Return the current status of a build: queued, running, passed, or failed."""
# Replace this with a call to your own build system.
return my_ci_client.get_build(build_id).status
build_agent = Agent(
role="Build Monitor",
goal="Start the build and report its final status",
backstory="An engineer who knows that builds take time.",
tools=[wait_tool, check_build_status_tool],
verbose=True,
)
monitor_task = Task(
description=(
"Start the build, then wait and re-check its status until it finishes."
),
expected_output="The final build status.",
agent=build_agent,
)
crew = Crew(agents=[build_agent], tasks=[monitor_task])
result = crew.kickoff()
```
## Arguments
| Argument | Type | Required | Description |
| :-------- | :------ | :------- | :----------------------------------------------------------------------------- |
| `seconds` | `float` | ✅ | How many seconds to wait. Must be zero or greater. |
| `reason` | `str` | ❌ | Optional note on what is being waited for. Echoed back in the tool's result. |
## Initialization Parameters
| Parameter | Type | Default | Description |
| :------------ | :------ | :------ | :----------------------------------------------------------------------------------- |
| `max_seconds` | `float` | `300` | Upper bound for a single wait. Longer requests are capped to this value, not rejected. |
## Capping Long Waits
A single call waits at most `max_seconds`. If an agent asks for more, the tool waits the
maximum and says so in its result, so the agent can call it again rather than fail:
```python Code
wait_tool = WaitTool()
wait_tool.run(seconds=3600)
# 'Waited 300 seconds. Requested 3600 seconds, capped at 300 seconds per call -
# call this tool again if more waiting is needed.'
```
Raise the cap when a workflow genuinely needs longer single pauses:
```python Code
wait_tool = WaitTool(max_seconds=1800)
```
## Async Support
The tool implements both sync and async execution, so it does not block the event loop when
awaited:
```python Code
import asyncio
async def main():
result = await wait_tool.arun(seconds=30, reason="waiting for the sandbox build")
print(result)
asyncio.run(main())
```