# Runtime limits and responsibilities

Understand AI usage, trigger semantics, credentials, provider limits and network access before publishing a Whenever workflow.

[Deploy your workflow](/deploy)

[Start for free](https://app.whenever.dev/)

## Code execution and optional AI

AI writes a workflow; the saved code then runs its rules. That is different from asking an agent to invent a new plan on every execution. It does not make every external result deterministic: provider data can change, and optional AI steps can vary their output.

AI model calls inside a running workflow can incur runtime AI usage. They are separate from the weekly allowance for AI building and editing. See [current plans and allowances](/pricing) rather than assuming that a building allowance covers every runtime model call.

An agent loop counts model turns and tool calls against the run's call budget. Put an explicit bound on the loop and validate tool arguments. The [AI assistant example](/docs/ai-agent-example) shows that pattern; it does not promise an unlimited number of turns.

## Schedules, polling and deliveries

A scheduled poll starts a run even if it finds no new items. Webhooks and managed events start executions on qualifying deliveries. One delivery can contain several records or messages; provider delivery behavior and workflow design determine the relationship between messages and runs. There is no universal polling cadence or message-to-run conversion.

Schedules fire at minute granularity, not second granularity, and use the configured timezone. A scheduled run has no delivery body. Keep trigger keys stable, particularly for webhooks: changing a webhook key issues a different URL. See [workflow triggers](/docs/triggers) and [webhook verification](/docs/webhooks).

## Credentials, permissions and provider limits

A listed integration is not a grant of access. Bind the operations your workflow calls, then connect the required account in Setup. HTTP and MCP destinations may require their own credentials, permissions and provider plan. Respect the provider's rate limits, quotas, pagination and payload limits; an execution allowance does not remove those constraints.

Keep non-sensitive settings in `ctx.config` and stored secrets in `ctx.secrets`. Do not log or return credential values. Validate external responses and record what a provider actually confirmed rather than reporting a successful outcome merely because a request was sent.

## Hosted-runtime reachability

APIs, MCP servers and database endpoints must be reachable from Whenever's hosted runtime. A service reachable only from your laptop, a private network or a local MCP process is not automatically reachable after deployment. Confirm the destination's network access requirements before choosing it for a hosted workflow.

## Failures and repeatable work

A step is a recorded boundary, not a resume point. A failed step ends its run. `RetryableError` records that a failure may be transient and can include a suggested delay; it does not schedule a retry, and a workflow is not automatically replayed.

Make external writes safe to repeat and implement any waiting or duplicate handling your process needs explicitly. Do not repeat an uncertain write without checking the destination's state. Read the [steps and error reference](/docs/steps) for the SDK contract.

## Related documentation

- [Prepare Setup and publish a workflow](/docs/deploy)
- [Integration ports and workspace bindings](/docs/integrations)
- [Workflow examples](/docs/examples)