> For the complete documentation index, see [llms.txt](https://developer.kizen.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.kizen.com/docs/concepts/agentic-workflows/agentic-workflow-safeguards.md).

# Agentic Workflow Safeguards

Understand the built-in safeguards that keep Agentic Workflows running safely: throttling, infinite-loop prevention, execution cancellation, and queue isolation.

{% hint style="success" %}
**Audience:** Administrators, developers, and solution architects

**Purpose:** Understand the built-in protections that govern how Agentic Workflows run, so you can design workflows that operate safely at scale and interpret platform behavior correctly when a safeguard engages.
{% endhint %}

### Overview

The <code class="expression">space.vars.automation</code> platform includes a set of built-in safeguards that protect data integrity, system performance, and execution reliability. Some are configurable and others operate automatically, but most stay in the background under normal conditions. They become apparent only when a workflow's design approaches or exceeds safe boundaries.&#x20;

This page explains what those protections are, when they engage, and how to work with them.

### Throttling

Throttling controls how frequently a trigger can start executions for a given <code class="expression">space.vars.entity</code> within a defined time window.

#### What It Is

Throttling is a configurable quiet-time window applied to a trigger. When it's enabled, the first trigger event for a specific <code class="expression">space.vars.entity</code> within the window creates an execution that runs normally. Additional events for that same <code class="expression">space.vars.entity</code> within the window are throttled and don't run the workflow again. Throttling limits how often the workflow runs for a given <code class="expression">space.vars.entity</code> within the window. It doesn't delay or reschedule events for later release. <code class="expression">space.vars.activity</code>-based triggers, such as <code class="expression">space.vars.activity</code> Logged and <code class="expression">space.vars.activity</code> Past Due, are never throttled themselves, but they can still open a window that throttles other trigger types on the same <code class="expression">space.vars.entity</code>. For details, see [Agentic Workflow Triggers](/docs/concepts/agentic-workflows/agentic-workflow-triggers.md).

#### Why It Exists

Throttling exists to prevent duplicate, concurrent executions when several trigger events fire for what is really a single change to a <code class="expression">space.vars.entity</code>. One change often produces more than one trigger event at nearly the same time. For example, several fields might be updated in a single save, or a <code class="expression">space.vars.entity</code> created and a field set simultaneously.&#x20;

Without throttling, each of those events starts its own execution, so the same logic runs multiple times on the same <code class="expression">space.vars.entity</code> at once. Throttling collapses them into one execution per window for that <code class="expression">space.vars.entity</code>, no matter how many times the trigger fires, which also reduces redundant load on the execution queue.

#### How It Behaves

The window opens when the first triggering event is processed and its execution is created. For later events on the same <code class="expression">space.vars.entity</code> within that window, throttling is checked at two points: when the execution is created and when the trigger is processed. If either check finds the event throttled, the platform still creates an execution but sets its status to Canceled instead of running the workflow. The workflow runs only once for that <code class="expression">space.vars.entity</code> within the window. When the window expires, the next event creates an execution and opens a new window.

Because trigger evaluation is asynchronous, throttling is checked against two windows: one measured from when the execution is created, and one measured from when the trigger is processed. Under load, events can be processed out of order or in batches, which can affect which events fall within the same window.

A throttled execution appears in execution history with a Canceled status, and its history log notes that it was throttled. Throttled executions don't appear on the <code class="expression">space.vars.entity</code>'s timeline. For more on execution statuses, see [Agentic Workflow Status & Lifecycle](/docs/concepts/agentic-workflows/agentic-workflow-status-and-lifecycle.md).

### Infinite Loop Prevention

The platform includes protections against infinite loops within a single workflow. It doesn't specifically detect loops that form across chains of workflows, so avoiding those is a design responsibility.

#### Go To Step Loop Detection

The Go To Step action lets an execution jump back to an earlier step. This becomes an infinite loop when the path that sends the execution back can repeat without ever resolving. The platform guards against this in two ways. First, at build time, the workflow builder won't let you save a loop unless it contains a goal or delay step, which gives the loop a way to resolve. Second, at runtime, if a Go To Step runs more than 20 times per hour, the platform pauses the execution with a Paused by Failure status. A paused execution isn't terminated, and you can restart it after you resolve the loop. For details, see [Agentic Workflow Status & Lifecycle](/docs/concepts/agentic-workflows/agentic-workflow-status-and-lifecycle.md).&#x20;

#### Cross-Workflow Loop Protection

When one workflow starts another, a loop can form across multiple workflows. This happens through a Start Agentic Workflow action, or through trigger chains where one workflow's actions fire another's triggers. For example, Workflow A starts Workflow B, which takes an action that re-triggers Workflow A. The platform doesn't specifically detect cross-workflow loops. It does limit each workflow to 3 executions in any 20-second window for the same trigger and Record, whether the workflow was started by itself or by another workflow. That limit can slow a runaway cycle, but it isn't a substitute for good design. When you build multi-workflow chains, make sure they can't cycle back on themselves.

### Cancel Execution

An execution can be canceled manually by a user with the right permissions, by a Stop Execution action step within the workflow, or automatically when the context <code class="expression">space.vars.entity</code> is archived. The platform also cancels an in-progress execution when someone edits the workflow in a way the execution can't safely continue from. For example, the step it's about to run was deleted, or an edit added, removed, or rearranged merged branches ahead of that step.

Any steps already in progress finish, but no further steps run. Canceled executions can't be resumed, and the cancellation is recorded in execution history. For the permission levels that can manually cancel an execution, see [Agentic Workflow Permissions](/docs/concepts/agentic-workflows/agentic-workflow-permissions.md).&#x20;

### Queue Isolation

Queue isolation protects the performance of normal operational workflows by keeping different categories of work in separate processing lanes, so high-volume or low-priority work can't crowd out time-sensitive executions.

#### What It Means

The lanes are organized by source, priority, or category. Queue isolation is a performance protection, not a functional limitation.

#### Why It Matters

Without isolation, a large bulk operation, such as starting a workflow on thousands of <code class="expression">space.vars.entities</code> at once, could consume the entire queue and delay all other processing for its duration. Isolation keeps bulk and low-priority work in its own lane so normal operational processing is unaffected. If you plan large-scale operations, factor this into your timing expectations.

#### What You Might See

Bulk starts may process each <code class="expression">space.vars.entity</code> more slowly than an individual-<code class="expression">space.vars.entity</code> start would, but the batch as a whole typically completes faster than the same work run through the interactive queue. Executions initiated via API may process differently from those initiated in the UI, and low-priority executions may appear to queue and process in batches rather than continuously. These aren't errors, but expected outcomes of queue isolation.

#### How to Influence It

Two factors affect how an execution is processed:

* **Processing priority** is the primary lever. It determines which lane an execution enters. Priority is either Regular or Low/Data Seeding.
* **Initiation method** also affects processing. An execution can be started from the UI, through the API, or in bulk.

The fastest way to run a workflow on a single <code class="expression">space.vars.entity</code> is to start it directly from that <code class="expression">space.vars.entity</code>. For details, see [Starting Agentic Workflows](/docs/concepts/agentic-workflows/starting-agentic-workflows.md). For lengthy Agentic Workflows that aren't time-sensitive, set them to Low/Data Seeding priority so they process in a separate lane and don't slow down your interactive workflows.

#### Where to Learn More

See [Agentic Workflow Execution & Process Model](/docs/concepts/agentic-workflows/agentic-workflow-execution-and-process-model.md) for the full asynchronous processing model, processing priority behavior, and priority inheritance.

### What's Next

Next, see [Agentic Workflow Data Model](/docs/concepts/agentic-workflows/agentic-workflow-data-model.md) for how workflows, executions, and step history are represented, related, and persisted, and how that data maps to the APIs and webhooks behind programmatic workflows.

<details>

<summary><strong>Related Topics</strong></summary>

* [Agentic Workflow Status & Lifecycle](/docs/concepts/agentic-workflows/agentic-workflow-status-and-lifecycle.md)
* [Agentic Workflow Execution & Process Model](/docs/concepts/agentic-workflows/agentic-workflow-execution-and-process-model.md)
* [Agentic Workflow Permissions](/docs/concepts/agentic-workflows/agentic-workflow-permissions.md)

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://developer.kizen.com/docs/concepts/agentic-workflows/agentic-workflow-safeguards.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.