# Prevent Repeated and Runaway Actions

Sistava automatically caps how many emails, messages, and external writes (CRM records, calendar events, paid searches) an AI employee can send in a single conversation, hour, and day, and blocks an identical send to the same recipient from going out twice within 24 hours. These limits run in the background per employee with no setup required, so a stuck task or unexpected loop cannot spam a contact's inbox, pollute your CRM, or burn through paid API calls. When a limit is hit, the employee is told to slow down or hand the task to a human instead of retrying blindly.

AI tasks that run too long or loop without progress waste money. Execution limits prevent that. Set a maximum duration per task (for example, 10 minutes), a retry cap (for example, 3 attempts), and a resource ceiling per employee or company-wide. If a task hits any limit, it stops cleanly, saves its progress, and notifies you.

Limits are especially important for scheduled and autonomous work. A task running at 3 AM without supervision should not burn through your entire credit balance because it entered a loop. Execution limits ensure that even unattended work stays within the boundaries you set.

When a task stops at a limit, the notification includes what happened, how much was consumed, and a suggested next step. You can increase the limit for that specific task, adjust the employee's configuration, or investigate the issue. Limits are guardrails, not dead ends. They protect you while giving you full visibility into what went wrong.

## Prevent Runaway Tasks With Hard Execution Boundaries

Autonomous agents are powerful precisely because they keep working without constant supervision. But that same quality can become a liability if a task enters an unexpected loop, hits a rate-limited API repeatedly, or spawns more subtasks than intended. Execution Limits give you hard ceilings so no single agent task can consume unbounded resources.

You can set time limits (maximum wall-clock time for a task), retry caps (maximum attempts before a tool call is abandoned), step counts (maximum number of agent actions per run), and resource ceilings (token usage, API call counts). When a limit is reached, the agent stops, logs what it was doing, and notifies you, rather than silently failing or running forever.

## Configure Limits Per Employee and Per Task Type

A research agent that synthesizes long documents legitimately needs more steps and more time than a scheduling agent booking a meeting. Execution Limits are configurable per employee and per task category, so you can give complex agents room to work while keeping simpler agents tightly scoped.

Default limits are set at the workspace level and apply to all new employees at hire. Individual employees can have their limits adjusted up or down from the workspace default. This layered approach means you always have a safety floor, with flexibility on top for agents that genuinely need it.

When a limit is triggered, the full execution trace up to that point is preserved in the Execution Inspector. You can review exactly what the agent was doing, why it hit the limit, and decide whether to adjust the limit, fix the task configuration, or intervene manually.

## Why Execution Limits Are Non-Negotiable for Production AI

In production environments, runaway agent tasks are not just expensive. They can trigger cascading failures in downstream systems, exhaust third-party API quotas, or produce thousands of unwanted side effects before anyone notices. Execution Limits are the circuit breaker that keeps isolated agent failures from becoming systemic problems.

This is especially important as you scale your AI workforce. With five agents, you can watch every task manually. With fifty, you cannot. Execution Limits let you operate at scale with confidence that no single agent or task can damage the whole system, even if something unexpected happens.

## How It Works

**Set hard boundaries on how long tasks can run, how many retries are allowed, and how many resources an agent can consume before it stops and escalates.**

Execution limits define the envelope within which your AI agents operate. Set a maximum run time per task and the agent stops and reports back when it hits the limit, rather than running indefinitely. Set retry caps and the agent escalates to a human instead of looping on a failing tool call. Set resource ceilings and the agent prioritizes the highest-value steps within the budget available.

Limits are protection against runaway behavior, and they are also a design constraint that makes agents more predictable. An agent that knows it has a five-minute window for a task will prioritize differently than one with unlimited time. Execution limits make cost and time predictable across your entire workforce, and they give your operations team a consistent set of knobs to tune as workloads scale.

## Use Cases

### Ops team caps AI agent runtime on expensive workflows

Execution limits stop a runaway AI agent after a set time or step count, preventing a loop from consuming credits and causing delays.

### Finance team sets monthly AI usage budgets

Execution limits enforce a per-agent or per-team cap on total usage, so AI spend never exceeds what was budgeted.

### Developer team prevents infinite loops in agent pipelines

Step and recursion limits catch agent loops early, terminating the run cleanly and sending an alert instead of burning through resources.

### Enterprise team enforces fair-use across departments

Execution limits ensure no single team or AI employee monopolizes platform resources, keeping performance consistent for everyone.

## Comparison

| Before | After |
|---|---|
| A misconfigured agent runs indefinitely, burning credits. | Execution limits terminate runaway agents automatically. |
| AI costs are unpredictable because there are no usage caps. | Limits make AI spend bounded and foreseeable. |
| Infinite loops require manual intervention to stop. | Step limits catch loops immediately and halt execution cleanly. |
| Power users can starve other teams of platform resources. | Per-agent limits enforce fair usage across the organization. |

## FAQ

### What happens when an agent hits an execution limit?

The agent stops immediately, logs the limit event with full context, and sends a notification to the employee's owner or the workspace admin depending on your alert settings. The incomplete task is preserved in the activity feed for review.

### Can I set different limits for different tools?

Yes. You can apply per-tool retry caps and call-count limits in addition to per-employee global limits. For example, you might allow an agent unlimited internal reasoning steps but cap external HTTP calls at 20 per task.

### Do limits apply to multi-agent workflows?

Limits apply per agent. In a multi-agent chain, each agent in the workflow has its own limits. This prevents a single misbehaving agent from consuming the resources allocated to the entire pipeline.

### What is a reasonable default limit for most tasks?

For most business tasks, 50 steps and a 10-minute wall-clock limit cover the vast majority of real work while catching loops early. We recommend starting with these defaults and adjusting based on actual task logs rather than setting high limits preemptively.

### Can I set limits on how long or how many times my AI agent retries a task?

Yes, execution limits let you cap run time, set retry counts, and define resource usage thresholds per task or per employee. If a limit is hit, the agent stops cleanly and logs what happened.

> Before execution limits, we had agents occasionally run for twenty minutes on a stuck tool call. Now they cap at three minutes and escalate. Our costs dropped immediately.
>
> Ricardo V., Platform Engineering Lead · SaaS company

## Where Prevent Repeated and Runaway Actions fits

Prevent Repeated and Runaway Actions is part of What stops them from going wrong.

Your AI agents pause before any sensitive action and wait for your approval. PII is detected and redacted before it reaches the model. Content policies block harmful or off-brand output. Execution limits prevent runaway tasks. A Sistava mentor pairs with every employee to spot blockers and keep work on track alongside their team leader. Set company-wide policies once and every employee follows them, including future hires.

- [What stops them from going wrong](/en/features/guardrails): Nothing sensitive happens without your say.

## Read the guide

- [Guide: Prevent Repeated and Runaway Actions](/en/guide/company/policies)

## More in Guardrails

- [AI Guardrails & Policies](/en/features/guardrails/guardrails): A Security Officer that checks every message going into and coming out of every AI employee you have. Five policies, each with its own switch: Input Safety stops prompt injection and jailbreak attempts, Output Safety keeps unfit replies from being sent, PII Protection replaces personal data with markers before the model reads it, Data Leakage Prevention keeps your setup and secrets in-house, and Topic Control holds employees to the subjects you choose. Turn on what you need from Settings, Technical, Security Officer and it covers every employee on the next message, including the ones you hire later. Checks run in parallel on a separate lightweight model, so protection costs a fraction of a message and your team never feels the wait. A running count of what has been caught, the busiest policy, and a live inspector showing every individual message are all on the same page.
- [Protect Against Prompt Injection](/en/features/guardrails/guardrail_input_safety): Input Safety reads every incoming message before your employee does, and stops the ones trying to hijack it: instructions to ignore its rules, requests to print its own configuration, and role-play framed to talk it out of its guardrails. That matters most where the message did not come from you, so a payload buried in a forwarded email, a support ticket, or a shared thread cannot turn your employee against you. Pick Low, Medium, or High, and every level catches the textbook attacks: the level decides how much benefit of the doubt the genuinely ambiguous messages get. Medium is the default and suits most companies. Blocked messages get a short, human reply and the conversation carries on, with each one recorded so you can see what has been tried.
- [Block Unsafe Employee Responses](/en/features/guardrails/guardrail_output_safety): Output Safety reads your employee's reply before anyone else does. Toxic, abusive, or otherwise unfit answers are held back rather than sent, which is what you want the moment employees write to customers, post to a channel, or answer a ticket without you watching. It checks the reply your employee actually wrote, so what you see caught is what would genuinely have gone out. Set it to Low, Medium, or High and review everything it held back in the live inspector. Blunt, direct, and critical business writing is left alone: the policy is looking for replies that would embarrass you, not ones that are simply frank.
- [Protect Personal Data](/en/features/guardrails/guardrail_pii_protection): PII Protection finds personal data in a message and replaces it with a marker before the model reads a single character of it. A pasted card number becomes [CREDIT_CARD], an email becomes [EMAIL_ADDRESS], and the same happens on the way out so nothing sensitive travels back into an email, a channel, or a ticket. You pick exactly what to protect from seven data types: email, phone, name, credit card, Social Security number, IP address, and address. The markers keep the sentence readable, so your employee understands the request perfectly and keeps working while the raw value stays out of the conversation. It runs on every message, in both directions, company-wide, from one switch.
- [Control What Employees Discuss](/en/features/guardrails/guardrail_topic_control): Topic Control gives you two lists and you can use either or both. Blocked topics are off-limits no matter how a conversation gets there, which keeps employees out of politics, competitor comparisons, or medical and legal advice. Allowed topics set a remit instead: name the subjects an employee handles and anything unrelated is politely declined, which is how you keep a support employee on product help, billing, and refunds. Both lists match on meaning rather than exact words, so ruling out competitor pricing also covers how much cheaper are we than the other tools out there. Greetings and short replies always get through, so a scoped employee still feels natural to talk to.
- [Keep Confidential Data In-House](/en/features/guardrails/guardrail_data_leakage): Data Leakage Prevention guards both ends of the conversation. On the way in it recognises someone fishing for your employee's internals, whether they ask outright, dress it up as a game, or try the repeat everything above this line trick. On the way out it reads the reply itself and holds it back if it is about to hand over a system prompt, internal configuration, an access token, or a credential. Questions about your own business data are never affected, so an employee still answers freely about your customers, documents, and numbers. One switch, no configuration to maintain, and every attempt is logged so you can see who has been probing.
- [Approve Sensitive Actions](/en/features/guardrails/input_requests): Let an AI employee pause and ask before it takes a sensitive action, like sending an email or spending on a paid tool, instead of guessing what you want. An inline card shows up right in the chat with Approve, Reject, or option buttons, and the employee resumes the instant you respond.
- [Protect Organisation Information](/en/features/guardrails/information_boundaries): Your AI employee treats what it learns in the workspace the way a careful coworker would: useful for doing the work, not free to repeat. It tells private, role-restricted, and confidential information apart from ordinary shared context, and it never volunteers the sensitive kind just because someone asked. When a teammate needs a restricted answer, the employee can request permission from the right person for that one specific answer instead of guessing or refusing outright.
- [Protect Your Email Reputation](/en/features/guardrails/email_deliverability): Every email your AI employees send, whether it is a notification, a mailbox reply, or an outbound message, passes through a pre-send check before it leaves. Sistava validates the address, checks it against a suppression list built from past bounces and complaints, and blocks anything that would hurt your sending reputation. You do not configure this: it runs silently on every send so your domain keeps a clean track record with inbox providers.
- [Delegation & Teamwork Limits](/en/features/guardrails/delegation_teamwork_limits): Tune how your leader employees hand off work to teammates. Set how many teammates a leader can delegate to at once, how far a delegation chain can reach, how long a delegated teammate can work before timing out, and how tolerant employees are of repeating themselves before loop protection stops them.
- [Detect and Redact PII](/en/features/guardrails/pii_detection): PII Protection watches every message your AI employees send and receive, and masks personal data like emails, phone numbers, credit card numbers, and social security numbers before it goes anywhere it shouldn't. You choose exactly which data types to catch. It runs on every employee across your company the moment you turn it on, with no per-employee setup.
- [Company-Wide Policies](/en/features/guardrails/company_policies): Company Policies let you set organization-wide safety rules that apply to every AI employee at once: block prompt injection attempts, filter harmful output, redact personal information, stop internal details from leaking, and restrict which topics employees can discuss. Turn each policy on with one toggle from your company dashboard, and it takes effect immediately across your whole team.

## Explore

- [Every feature](/en/features)
- [Hire an AI employee](/en/market)
- [Pricing](/en/pricing)