Skip to main content
Rate limits control how many agent interactions can run at the same time. They do not limit how many you can run per day — only how many can be active simultaneously.

​
Quick Reference

Once an agent interaction finishes, it frees up a slot for the next one.

​
How Rate Limits Work

Every time an agent interaction starts, the system checks whether your organization has an available slot. If it does, the execution starts immediately. If all slots are in use, the request is either queued or rejected depending on your plan.
1

Request arrives

An agent interaction starts — whether from the UI, API, Slack, Teams, or a scheduled trigger.
2

Slot check

The system checks how many executions are currently running across your organization against your concurrency limit.
3

Outcome

  • Under limit — execution starts immediately
  • At limit + Enterprise plan — request is queued and starts automatically when a slot opens
  • At limit + Pro — request is rejected

​
Agent Rate Limits

Agent rate limits control how many agent interactions can run at the same time across your organization.

​
Limits by Plan

​
What Counts Toward the Limit

Counts

  • Any agent interaction that is currently running (actively processing a request or executing tools)
  • Interactions from all channels: web UI, Slack, Teams, API, and triggers

Does NOT Count

  • Interactions that have finished (completed or failed)
  • Interactions that are queued (waiting for a slot)
  • Interactions that are idle (conversation open but agent is not actively working)
  • The Custom Operator Builder AI assistant
  • The App Policy builder assistant
Builder assistants (Custom Operator Builder, App Policy Builder) are excluded from agent rate limits so that building is never blocked by agent concurrency.

​
How the Limit Is Determined

The system determines your organization’s limit in this order:
  1. Custom organization limit — A custom agent concurrency limit on the org, if set.
  2. Plan default — Falls back to the plan-based default shown above.
  3. Per-user cap (optional) — An optional cap on a custom role that restricts how many interactions a single user can run. When a user is in multiple custom roles, the most generous cap across their roles applies.
Setup:
  • Organization concurrency limit: 100
  • A user group has a per-user cap of 10
Result:
  • The organization can have up to 100 interactions at once across all members
  • Any user in that group can have at most 10 of those 100 running at once
  • Both limits must be satisfied for a new interaction to start
This lets admins prevent a single user from consuming the entire org’s capacity.

​
Automatic Slot Cleanup

If an agent interaction crashes or is abandoned without finishing properly, the slot it was using is automatically freed after approximately 2 hours. This means you will never get permanently stuck at your limit due to a stuck interaction. Under normal circumstances, slots are released immediately when an interaction finishes — the 2-hour cleanup is only a safety net.

​
What Happens When You’re Rate Limited

How the system communicates rate limiting depends on where the interaction comes from:

​
Web UI

When chatting with an agent in the browser:
  • Enterprise: The UI shows a “queued” indicator and waits up to 5 minutes for a slot to open. If a slot opens, the interaction starts automatically. If not, you are notified.
  • Pro: An error message is shown: “Too many concurrent agent interactions. Please try again shortly.”

​
API

When starting an agent via the API:
  • Enterprise: If the limit is hit, the request is queued. The API returns the interaction with a queued status and a queue_position so you can track progress.
  • Pro: The API returns HTTP 429 (Too Many Requests).
Queued (Enterprise):
Rate Limited:

​
Slack

When an agent receives a Slack message:
  • Enterprise: If queued, a message is posted in the thread: “Your agent interaction is queued (position #N). It will be processed shortly.”
  • Pro: An ephemeral message is sent: “You have too many agent interactions running at the moment. Please try again shortly.”

​
Microsoft Teams

Follows the same pattern as Slack — Enterprise users see a queued notification, others see an error message.

​
Scheduled & Event-Based Triggers

  • Enterprise: If the limit is hit, the triggered interaction is queued and will start when capacity is available.
  • Pro: The trigger execution is skipped.

​
How the Queue Works

When an Enterprise organization hits the rate limit, requests are placed in a queue instead of being rejected.
  • When a running execution finishes and frees a slot, the next queued item starts automatically
  • The user who freed the slot gets slight priority — their own queued items are checked first, then the org-wide queue
  • Within each queue, items are processed in the order they were submitted (first in, first out)
  • If a queued item can’t start because of a per-user cap, it is moved to that user’s individual queue (not dropped)

​
Tips for Avoiding Rate Limits

Stagger Your Triggers

If you’re starting many agent interactions at once (e.g., via webhooks), add small delays between them so they don’t all compete for slots at the same time.

Keep Runs Short

Shorter agent interactions free up slots faster. Give agents focused tasks to reduce their total execution time.

Upgrade Your Plan

If you consistently hit limits, consider upgrading. Enterprise plans have the highest limits and also unlock automatic queuing so requests are never lost.
Enterprise organizations can request custom concurrency limits that exceed the defaults. Contact your account manager or support@gumloop.com to adjust:
  • Agent concurrency — the org-wide limit on simultaneous agent interactions
  • Per-user caps via user groups — restrict individual users within the org
These are set at the organization level and apply to all members.

​
Summary

Credits

Learn about credit costs for agents

Custom Roles

Configure custom roles and per-user limits